What Firewall Logging & Monitoring Is and Why It Matters in 2026
Firewall logging and monitoring is the continuous collection, analysis, and alerting on network traffic events captured by firewall devices. Every packet decision—permit, deny, NAT translation, VPN tunnel establishment—generates a log entry that security teams parse to detect intrusions, troubleshoot connectivity failures, and satisfy compliance mandates. In 2026, with CERT-In requiring Indian organizations to retain logs for 180 days and the Digital Personal Data Protection Act imposing breach-notification deadlines, firewall logs are the first artifact forensic teams examine during incident response. Without structured logging to Syslog servers, SNMP traps for real-time alerts, and SIEM integration for correlation, organizations operate blind—unable to prove compliance, reconstruct attack timelines, or identify lateral movement across VLANs.
Modern firewalls generate millions of events daily. A single Cisco ASA at a mid-sized enterprise in Bengaluru's Electronic City can produce 50,000 connection logs per hour during business peaks. Manual review is impossible; automated pipelines that feed logs into centralized SIEM platforms like Splunk, QRadar, or open-source Wazuh become mandatory. The three pillars—Syslog for bulk log transport, SNMP for device health and threshold alerts, SIEM for cross-device correlation—work in concert to transform raw firewall data into actionable intelligence.
How Firewall Logging Works Under the Hood
When a firewall processes a packet, the decision engine evaluates ACLs, NAT rules, application signatures, and threat intelligence feeds. Each decision point can trigger a log event. The firewall writes this event to an internal buffer—typically 4-8 MB on Cisco ASA, 16 MB on Palo Alto PA-Series—then forwards it to configured destinations via UDP port 514 (Syslog), SNMP traps on UDP 162, or proprietary APIs for SIEM connectors.
Syslog Message Anatomy
A Syslog message follows RFC 5424 structure: priority value (facility × 8 + severity), timestamp, hostname, application identifier, process ID, message ID, and structured data. Cisco firewalls use facility code 20 (local4) by default. Severity ranges from 0 (emergency) to 7 (debug). A typical ASA deny log looks like:
<164>1 2026-01-15T14:23:11+05:30 ASA-BLR-01 %ASA-4-106023: Deny tcp src outside:203.0.113.45/52341 dst inside:10.10.10.50/443 by access-group "outside_in" [0x8a3f2b1c, 0x0]
The priority 164 decodes to facility 20, severity 4 (warning). The message ID 106023 maps to an ACL deny event. The hexadecimal values are internal correlation tags. SIEMs parse these fields using regex or built-in parsers to populate normalized schemas—source IP, destination IP, port, action, rule name.
SNMP Trap Generation
SNMP traps are asynchronous notifications sent when thresholds breach or critical events occur—interface down, CPU above 80%, VPN tunnel flap. Cisco firewalls support SNMPv2c and SNMPv3. The firewall's SNMP agent constructs a trap PDU containing OID (object identifier) sequences from the CISCO-FIREWALL-MIB. For example, OID 1.3.6.1.4.1.9.9.147.1.2.2.1.1.5 represents connection table overflow. Network management systems like SolarWinds or PRTG subscribe to these traps and trigger runbooks—page the NOC, restart a service, block an IP via API.
SIEM Integration Mechanisms
SIEMs ingest firewall logs through three methods: Syslog forwarding (most common), API polling (Palo Alto Panorama REST API, Fortinet FortiAnalyzer API), and agent-based collection (Splunk Universal Forwarder installed on a log concentrator). Once ingested, the SIEM normalizes vendor-specific formats into a common schema—CIM (Common Information Model) in Splunk, QRadar's event taxonomy. Correlation rules then fire: "If firewall denies outbound DNS to non-corporate resolver AND endpoint queries same domain via DoH within 60 seconds, alert on DNS tunneling attempt."
In our HSR Layout lab, we benchmarked a Cisco Firepower 2130 forwarding logs to an on-premises Wazuh cluster. At 12,000 events per second, the firewall's CPU utilization remained below 15 percent, but the Wazuh indexer required NVMe storage to maintain sub-second search latency. This real-world constraint shapes our full-stack network security course in Bangalore, where students configure multi-tier logging architectures during the 4-month paid internship at our Network Security Operations Division.
Syslog vs SNMP vs SIEM Integration—When to Use Each
Organizations often conflate these three technologies. Each serves distinct purposes and operates at different layers of the monitoring stack. Understanding their boundaries prevents over-engineering and ensures compliance without drowning teams in noise.
| Dimension | Syslog | SNMP | SIEM Integration |
|---|---|---|---|
| Primary Function | Bulk event transport | Device health monitoring & alerting | Cross-device correlation & forensics |
| Protocol & Port | UDP 514 (RFC 5424) or TCP 6514 (TLS) | UDP 161 (queries), 162 (traps) | Varies—Syslog, API, agent push |
| Data Volume | High—millions of events/day | Low—threshold breaches only | Very high—aggregates all sources |
| Latency | Near real-time (sub-second) | Real-time (immediate trap) | Seconds to minutes (indexing lag) |
| Use Case | Compliance logging, ACL troubleshooting | Capacity planning, uptime SLAs | Threat hunting, incident response |
| Retention | Days to weeks (raw logs) | Months (SNMP metrics in TSDB) | Months to years (indexed + archived) |
| Indian Compliance | CERT-In 180-day mandate | RBI cyber-resilience framework | DPDP breach investigation |
A typical deployment at Cisco India's Bengaluru campus uses all three: Syslog feeds raw ASA and Firepower logs to a central rsyslog cluster for CERT-In compliance; SNMP traps alert the NOC when firewall CPU exceeds 75 percent or VPN peer counts drop; Splunk Enterprise ingests both Syslog streams and SNMP trap logs, correlating firewall denies with endpoint EDR alerts to detect ransomware C2 beaconing. This layered approach is the industry standard we teach in the Firewall & Network Security Fundamentals course.
Configuring Syslog on Cisco ASA and Firepower
Cisco firewalls offer granular control over which events to log, where to send them, and at what severity. Misconfigurations—logging debug-level events to a remote server, using UDP without rate-limiting—can saturate WAN links or overwhelm Syslog servers.
Cisco ASA Syslog Configuration
! Define the Syslog server
logging host inside 10.10.10.100
! Set facility code (local4 is default)
logging facility 20
! Enable logging
logging enable
! Set severity threshold (informational = level 6)
logging trap informational
! Log ACL denies
logging message 106023 level warnings
! Enable timestamp with timezone
logging timestamp
! Buffer local logs (4096 KB)
logging buffer-size 4096
logging buffered informational
! Disable console logging to prevent CPU spikes
no logging console
The logging host command specifies the Syslog server IP. The inside keyword indicates the interface through which the server is reachable. The logging trap informational line sets the minimum severity; only messages at level 6 or lower (0-6) are forwarded. Message ID 106023 (ACL deny) is explicitly set to warnings (level 4) to ensure it's captured even if the global trap level is higher.
Cisco Firepower Threat Defense (FTD) via FMC
Firepower uses Firepower Management Center (FMC) for centralized policy. Navigate to Devices → Platform Settings → Syslog. Create a Syslog server object with IP, port, protocol (UDP/TCP), and facility. Under Policies → Access Control → Logging, enable logging for specific rules. Connection events generate message ID 430002; intrusion events use 430003. FTD can send logs to multiple destinations simultaneously—one for compliance archival, another for real-time SIEM ingestion.
Rate-Limiting to Prevent Log Floods
A DDoS attack or misconfigured application can generate millions of deny logs per minute, overwhelming both the firewall and the Syslog server. Cisco ASA supports rate-limiting per message ID:
logging rate-limit message 106023 level 4 rate 100
This limits message 106023 to 100 logs per second. Exceeding this rate triggers a summary log indicating suppression count. Without rate-limiting, we observed a single ASA 5516-X in our lab saturate a 1 Gbps link during a SYN flood simulation, rendering the management plane unresponsive.
Configuring SNMP Monitoring on Firewalls
SNMP provides real-time visibility into firewall health—CPU, memory, interface utilization, connection table size, VPN tunnel status. SNMPv3 adds authentication and encryption, mandatory for production environments to prevent MitM attacks that expose community strings.
Cisco ASA SNMPv3 Configuration
! Create SNMP group with auth and priv
snmp-server group NH-SecOps v3 priv
! Create user with SHA auth and AES-256 encryption
snmp-server user nhmonitor NH-SecOps v3 auth sha MyAuthPass123 priv aes 256 MyPrivPass456
! Define allowed NMS host
snmp-server host inside 10.10.10.200 version 3 nhmonitor
! Enable traps for critical events
snmp-server enable traps snmp authentication linkup linkdown
snmp-server enable traps syslog
snmp-server enable traps ipsec start stop
! Set location and contact
snmp-server location "HSR Layout, Bengaluru"
snmp-server contact "noc@networkershome.com"
The snmp-server enable traps commands specify which events generate traps. The ipsec start stop trap fires when VPN tunnels establish or tear down—critical for monitoring site-to-site connectivity to branch offices. The NMS at 10.10.10.200 polls OIDs like 1.3.6.1.4.1.9.9.147.1.2.1.1.1 (connection count) every 5 minutes and graphs trends.
Key OIDs for Firewall Monitoring
- 1.3.6.1.4.1.9.9.109.1.1.1.1.3 — CPU utilization (5-second average)
- 1.3.6.1.4.1.9.9.109.1.1.1.1.12 — Memory pool used
- 1.3.6.1.4.1.9.9.147.1.2.2.2.1.5 — Connection table utilization percentage
- 1.3.6.1.4.1.9.9.171.1.2.3.1.6 — Interface input errors
- 1.3.6.1.4.1.9.9.392.1.3.35 — VPN tunnel status (up/down)
Polling these OIDs every 5 minutes provides baseline metrics. Threshold alerts—CPU above 80 percent for 10 minutes, connection table above 90 percent—trigger automated responses. At Akamai India's Mumbai edge nodes, SNMP traps from firewalls integrate with PagerDuty to page on-call engineers within 30 seconds of a tunnel flap, minimizing customer-facing downtime.
SIEM Integration Patterns and Correlation Rules
A SIEM transforms firewall logs from isolated events into a narrative of attacker behavior. Correlation rules join events across time and data sources—firewall denies, endpoint process creation, DNS queries, authentication failures—to detect multi-stage attacks that evade single-point defenses.
Common Firewall-Centric Correlation Rules
Port Scan Detection: If source IP generates more than 50 unique destination ports within 60 seconds and firewall logs show denies on 80 percent of those ports, flag as reconnaissance. This rule catches tools like Nmap or Masscan probing for open services.
Lateral Movement via RDP: If firewall permits internal-to-internal RDP (TCP 3389) from a workstation VLAN to a server VLAN, AND the source IP has no prior RDP history in the past 30 days, AND endpoint logs show no interactive logon, alert on potential Pass-the-Hash attack. This correlation requires joining firewall connection logs with Windows Event ID 4624 (logon) and 4625 (failed logon).
Data Exfiltration via DNS Tunneling: If firewall permits outbound DNS to non-corporate resolvers (not 8.8.8.8, not internal), AND query volume exceeds 100 requests per minute, AND query lengths average above 60 characters, flag as potential DNS tunneling. Attackers encode data in subdomain labels to bypass DLP.
VPN Brute-Force: If firewall logs show more than 10 failed VPN authentication attempts (message ID 113005 on ASA) from a single source IP within 5 minutes, followed by a successful authentication, alert on credential stuffing. This rule helped our internship students at HCL's Noida SOC block 47 brute-force campaigns in Q4 2025.
Splunk Search Example
index=firewall sourcetype=cisco:asa action=denied
| stats dc(dest_port) as unique_ports by src_ip
| where unique_ports > 50
| eval severity="high"
| table src_ip unique_ports severity
This SPL (Search Processing Language) query identifies source IPs that hit more than 50 unique destination ports in denied connections—classic port scan signature. The dc() function counts distinct values. Results feed into a dashboard tile that updates every 60 seconds, giving analysts real-time visibility into reconnaissance activity.
QRadar Custom Rule
QRadar uses AQL (Ariel Query Language) and a rule wizard. A custom rule for lateral RDP movement:
- When: Event matches "Firewall Permit" AND destination port = 3389 AND source IP in CIDR 10.20.0.0/16 (workstation VLAN) AND destination IP in CIDR 10.30.0.0/16 (server VLAN)
- And: No event in past 30 days where same source IP connected to same destination IP on port 3389
- Then: Create offense with category "Lateral Movement" and magnitude 7
QRadar's offense management groups related events into a single incident, reducing alert fatigue. Analysts pivot from the offense to raw logs, PCAP (if packet capture is enabled), and endpoint telemetry in a unified interface.
Common Pitfalls and CCIE Security Interview Gotchas
Firewall logging is a frequent topic in CCIE Security lab exams and technical interviews at Cisco India, Barracuda, and Aryaka. Interviewers probe understanding of protocol mechanics, not just CLI syntax. Below are scenarios that trip up candidates during our mock interview sessions at Networkers Home.
UDP Syslog Packet Loss
Scenario: "Your firewall shows 100,000 deny logs in the local buffer, but the Syslog server only received 87,000. Why?"
Answer: Syslog over UDP (port 514) is connectionless and does not retransmit lost packets. During network congestion or if the Syslog server's receive buffer overflows, packets drop silently. The firewall increments the logging queue counter visible via show logging. Solutions: switch to TCP Syslog (port 6514 with TLS for encryption), increase the Syslog server's net.core.rmem_max kernel parameter, or deploy a local log concentrator (rsyslog with disk buffering) that forwards to the central SIEM over reliable transport.
Logging Buffer Wraparound
Scenario: "You configure logging buffered debugging on an ASA. After 10 minutes, you run show logging and see only the most recent 2 minutes of logs. What happened?"
Answer: The internal buffer is circular and finite (default 4 MB). Debug-level logging generates massive volume—every packet inspection, every NAT translation. The buffer fills in seconds and overwrites the oldest entries. Debug logging should never run in production; use it only during controlled troubleshooting with logging buffered informational as the baseline. For persistent storage, always forward to an external Syslog server.
SNMP Trap Storms
Scenario: "An interface flaps every 30 seconds due to a faulty SFP. Your NMS receives 2,880 linkup/linkdown traps per day. How do you prevent trap storms from masking other critical alerts?"
Answer: Implement trap throttling on the firewall using snmp-server enable traps snmp linkup linkdown rate-limit 10 (Cisco IOS-XE syntax; ASA lacks native rate-limiting for traps). Alternatively, configure the NMS to suppress duplicate traps within a time window—SolarWinds calls this "alert suppression," PRTG calls it "dependency rules." The root fix is replacing the faulty SFP, but throttling prevents operational disruption during the maintenance window.
Timezone Mismatches in Multi-Site Deployments
Scenario: "Your Bengaluru firewall logs show timestamp 14:23:11, your Mumbai firewall shows 14:23:11, but the events are 30 minutes apart in the SIEM timeline. Why?"
Answer: One firewall uses IST (UTC+5:30), the other uses UTC. Syslog messages include timezone offsets only if logging timestamp is configured with the timezone option. Without it, the SIEM assumes UTC or the server's local time. Best practice: configure all firewalls with clock timezone IST 5 30 and ntp server 0.in.pool.ntp.org to synchronize clocks. The SIEM should normalize all timestamps to UTC internally and display in the analyst's local timezone.
Message ID Filtering Gaps
Scenario: "You configure logging message 106023 level warnings to capture ACL denies, but you're not seeing denies from object-group ACLs. Why?"
Answer: Object-group ACL denies generate message ID 106100, not 106023. Cisco uses different message IDs for standard ACLs, extended ACLs, and object-group ACLs. You must enable both: logging message 106023 level warnings and logging message 106100 level warnings. This granularity allows filtering noise (e.g., suppress 106023 for known scanner IPs) while preserving critical denies. Our full-stack network security course in Bangalore includes a 3-hour lab where students reverse-engineer message IDs from live ASA and Firepower logs to build comprehensive logging policies.
Real-World Deployment Scenarios Across Indian Enterprises
Firewall logging architectures vary by organization size, compliance requirements, and threat landscape. Below are three deployment patterns we observe across Networkers Home's 800+ hiring partners, including Cisco India, HCL, Akamai, Aryaka, Movate, Wipro, TCS, Infosys, IBM, and Accenture.
Scenario 1: Mid-Sized BFSI (Banking, Financial Services, Insurance) in Mumbai
A private bank with 200 branches uses Cisco ASA 5525-X at each branch and Firepower 4150 at the data center. RBI's cyber-resilience framework mandates 180-day log retention and 4-hour incident response SLAs. The architecture:
- Branch firewalls forward Syslog over MPLS to regional log concentrators (Ubuntu 22.04 running rsyslog with TLS).
- Regional concentrators aggregate logs from 50 branches each, compress, and forward to the central SIEM (IBM QRadar) over dedicated 10 Gbps links.
- SNMP traps from all firewalls feed into SolarWinds NPM for capacity planning. Threshold alerts (CPU > 75%, connection table > 85%) trigger ServiceNow tickets.
- QRadar correlation rules detect card-not-present fraud patterns: if firewall permits outbound HTTPS to a payment gateway from a branch IP, AND the transaction volume exceeds 3 standard deviations from the branch's 30-day baseline, AND endpoint logs show no user activity, alert on potential POS malware exfiltration.
Retention: hot storage (NVMe SSD) for 30 days, warm storage (SAS HDD) for 150 days, cold storage (tape archive) for 7 years per RBI guidelines. This tiered approach balances search performance with cost—NVMe at ₹15 per GB, tape at ₹0.50 per GB.
Scenario 2: E-Commerce Unicorn in Bengaluru
A Flipkart-scale platform processes 10 million transactions daily during festival sales. Palo Alto PA-5450 firewalls at AWS Direct Connect edge and on-premises data centers generate 50 GB of logs per hour. The architecture:
- Palo Alto firewalls stream logs via Panorama to AWS S3 buckets (one bucket per region for latency optimization).
- AWS Lambda functions trigger on S3 object creation, parse logs, and push normalized events to Amazon OpenSearch Service (managed Elasticsearch).
- OpenSearch Dashboards provide real-time visualization—top denied IPs, top attacked URLs, geo-distribution of threats.
- Correlation: OpenSearch Alerting plugin fires webhooks to Slack when firewall denies exceed 10,000 per minute from a single ASN, indicating a DDoS attack. The webhook triggers AWS WAF rule updates via API to block the ASN at the CDN edge.
Cost optimization: S3 Intelligent-Tiering moves logs older than 90 days to Glacier, reducing storage cost by 80 percent. OpenSearch uses UltraWarm nodes (S3-backed) for 91-365 day retention, keeping only 90 days in hot storage.
Scenario 3: Managed Security Service Provider (MSSP) Serving 200+ SMBs
An MSSP in Hyderabad manages firewalls for 200 small and medium businesses—retail chains, clinics, law firms. Each customer has a Fortinet FortiGate 60F. The architecture:
- FortiGate devices forward logs to FortiAnalyzer (on-premises VM cluster) via proprietary OFTP protocol (TCP 514).
- FortiAnalyzer provides per-customer log segregation (ADOMs—Administrative Domains), ensuring Customer A cannot see Customer B's logs.
- SNMP traps from all FortiGates feed into PRTG Network Monitor. The MSSP's NOC receives SMS alerts when any customer firewall's WAN interface goes down.
- Automated reporting: FortiAnalyzer generates monthly compliance reports (PCI-DSS, ISO 27001) per customer, exported as PDFs and emailed via scheduled tasks.
Scalability: FortiAnalyzer scales horizontally—adding a second VM doubles log ingestion capacity. The MSSP charges customers per GB of log storage, creating a revenue stream from logging infrastructure.
These scenarios reflect the diversity of logging strategies our students encounter during the 4-month paid internship at Networkers Home's Network Security Operations Division, where they rotate through SOC analyst, firewall admin, and SIEM engineer roles.
How Firewall Logging Connects to CCNA, CCNP, and CCIE Syllabus
Firewall logging appears across Cisco's certification tracks, with increasing depth at each level. Understanding where it fits helps candidates prioritize study time and map real-world skills to exam objectives.
CCNA Security (Retired, but Concepts Persist in CCNA 200-301)
CCNA 200-301 includes basic security fundamentals under the "Security Fundamentals" domain (15 percent of exam). Candidates must explain the purpose of Syslog and identify severity levels (0-7). A sample question: "Which Syslog severity level indicates a system is unusable?" (Answer: 0—Emergency). No CLI configuration is tested; it's purely conceptual.
CCNP Security (SCOR 350-701 Core Exam)
SCOR dedicates 20 percent of the blueprint to "Secure Network Access, Visibility, and Enforcement." Candidates must configure Syslog on Cisco ASA and Firepower, interpret message IDs, and explain the difference between local buffered logging and remote logging. A lab task might be: "Configure the ASA to send only critical and alert-level messages to Syslog server 192.168.1.100, and suppress message ID 106023 for source IP 203.0.113.0/24."
SCOR also covers SNMP configuration (SNMPv3 with auth and priv) and NetFlow/IPFIX for traffic visibility. Candidates must explain how NetFlow complements Syslog—NetFlow provides flow-level metadata (source/dest IP, port, byte count) without payload inspection, while Syslog captures firewall decisions and application-layer events.
CCIE Security (Lab Exam v6.0)
The CCIE Security lab includes a troubleshooting module where logging is often the key to diagnosing failures. A scenario: "Users report intermittent VPN disconnects. ASA logs show message ID 113039 (Group = XYZ, IP = 203.0.113.45, Session disconnected. Session Type: IPsec, Duration: 0h:00m:12s, Bytes xmt: 0, Bytes rcv: 0). Identify the root cause."
The zero-byte transfer and 12-second duration indicate Phase 2 (IPsec SA) negotiation failure. Candidates must correlate this with IKEv2 debug logs (message ID 713236) showing mismatched encryption domains or PFS group mismatch. The lab tests ability to parse logs under time pressure—8 hours to complete all modules.
CCIE also requires designing logging architectures for high-availability scenarios: if the primary Syslog server fails, how does the firewall fail over to the secondary? (Answer: configure multiple logging host commands; ASA tries them in order until one succeeds.)
Mapping to Networkers Home's Course Structure
Our Firewall & Network Security Fundamentals course aligns with CCNP Security SCOR objectives, then extends into CCIE-level troubleshooting and SIEM integration (not covered in Cisco exams). Students progress through:
- Weeks 1-2: Syslog theory, severity levels, RFC 5424 message format.
- Weeks 3-4: Hands-on ASA and Firepower Syslog configuration in our HSR Layout lab (24×7 rack access).
- Weeks 5-6: SNMP configuration, OID polling, trap handling in SolarWinds and PRTG.
- Weeks 7-10: SIEM integration—Splunk and QRadar labs, building correlation rules, tuning false positives.
- Weeks 11-16: Capstone project—design a multi-site logging architecture for a mock enterprise, present to a panel of CCIE instructors.
Graduates receive an 8-month verified experience letter and free access to NHPREP.COM mock tests for 12 months, covering CCNP Security and CCIE Security lab scenarios.
Frequently Asked Questions
What is the difference between Syslog and NetFlow for firewall visibility?
Syslog captures event-driven logs—permit, deny, NAT translation, authentication success/failure—with contextual details like rule name, user identity, and application signature. NetFlow (or IPFIX on newer platforms) exports flow records—aggregated metadata about conversations (5-tuple: source IP, dest IP, source port, dest port, protocol) with byte/packet counts and timestamps. Syslog answers "Why was this blocked?" and "Who did this?"; NetFlow answers "How much traffic?" and "Which applications consume bandwidth?" Both are complementary. A typical deployment uses Syslog for security events and NetFlow for capacity planning and anomaly detection (e.g., sudden 10x increase in outbound HTTPS traffic indicates data exfiltration).
How do I prevent Syslog from overwhelming my firewall's CPU?
Limit logging to informational level or higher (logging trap informational), never debug in production. Enable rate-limiting per message ID (logging rate-limit message 106023 level 4 rate 100). Use TCP Syslog with TLS instead of UDP to use flow control—if the Syslog server is slow, TCP backpressure prevents the firewall from queuing unlimited logs in memory. Offload high-volume logs (connection events) to NetFlow; reserve Syslog for security-relevant events (denies, authentication, policy changes). In our lab, a Firepower 2130 at debug level consumed 60 percent CPU just formatting and transmitting logs; at informational level, CPU dropped to 8 percent under the same traffic load.
Can I send firewall logs directly to Splunk without a Syslog server?
Yes, but it's not recommended for production. Splunk can receive Syslog directly on port 514 via a TCP/UDP input. However, this creates a single point of failure—if Splunk is down for maintenance or indexer cluster rebalancing, logs are lost (UDP) or the firewall's TCP send buffer fills, potentially impacting performance. Best practice: deploy a Syslog relay (rsyslog, syslog-ng, or Splunk Heavy Forwarder) that buffers logs to disk and forwards to Splunk. The relay survives Splunk outages and provides a local copy for emergency troubleshooting. At Aryaka's Bengaluru NOC, we observed a 4-hour Splunk outage during a botched upgrade; the rsyslog relay buffered 180 GB of logs and replayed them once Splunk recovered, preserving the timeline for a concurrent fraud investigation.
What Syslog severity level should I use for compliance logging?
CERT-In and PCI-DSS require logging all access control decisions (permit and deny), authentication events, and administrative changes. This maps to Syslog severity 4 (warning) and above. Configure logging trap warnings as the baseline. For PCI-DSS, also enable logging of successful authentications (severity 5—notification) to satisfy Requirement 10.2.5 ("Use of identification and authentication mechanisms"). For DPDP Act breach investigations, you need user-to-IP mappings, which require logging DHCP assignments (if the firewall is the DHCP server) or correlating firewall logs with DHCP server logs via SIEM. Over-logging (debug or informational for all events) generates noise and inflates storage costs without compliance benefit.
How long should I retain firewall logs?
India: CERT-In mandates 180 days (6 months) for all logs related to cyber incidents. PCI-DSS requires 1 year of audit logs with 3 months immediately available for analysis. ISO 27001 defers to organizational risk assessment but typically 1 year minimum. GDPR (for Indian subsidiaries of EU companies) requires retention "no longer than necessary" but allows longer retention for security purposes—courts have upheld 2 years as reasonable. Practical recommendation: 90 days hot (fast search), 270 days warm (slower search, compressed), 2 years cold (archive, restored on-demand). Use SIEM's tiered storage or S3 lifecycle policies to automate transitions. At Infosys, firewall logs are kept for 7 years to support client contract disputes and litigation holds, stored on tape at ₹0.40 per GB.
What is the best SIEM for a small organization with limited budget?
Open-source Wazuh is the most capable free SIEM for firewall log analysis. It includes built-in decoders for Cisco ASA, Palo Alto, Fortinet, and pfSense. Wazuh agents can run on the firewall itself (if supported) or on a log concentrator. The Wazuh manager correlates events, runs compliance checks (PCI-DSS, GDPR, NIST), and provides a Kibana-based dashboard. For organizations with 5-10 firewalls generating under 5 GB/day, a single Wazuh manager on a 4-core, 16 GB RAM VM suffices. Commercial alternatives: Splunk Free (500 MB/day limit, no alerting), Graylog Open Source (unlimited ingestion, limited streams), Elastic Stack (self-managed, requires expertise). We deploy Wazuh in our internship program because it's production-grade, free, and mirrors the architecture at HCL and Movate SOCs where our students get placed.
How do I correlate firewall logs with endpoint logs in a SIEM?
The join key is typically source IP address and timestamp. Firewall logs provide the network-layer view (IP 10.10.10.45 connected to 203.0.113.100:443 at 14:23:11). Endpoint logs (Windows Event Logs, Sysmon, EDR telemetry) provide the process-layer view (chrome.exe PID 4512 on host DESKTOP-ABC, user jdoe, opened socket to 203.0.113.100:443 at 14:23:11). The SIEM joins these on IP and timestamp (with a tolerance window—±5 seconds—to account for clock skew). The correlation enriches the firewall event: "User jdoe on DESKTOP-ABC (10.10.10.45) accessed suspicious domain via chrome.exe." Advanced SIEMs use asset databases to map IP to hostname, hostname to user, user to department, enabling queries like "Show all firewall denies from Finance department in the past 7 days." This requires maintaining an accurate CMDB (Configuration Management Database) and syncing it to the SIEM hourly via API or CSV import.