Log Data — Flashcards

Traditional firewall log fields: (1) Source IP and port, (2) Destination IP and port, (3) Protocol (TCP/UDP/ICMP), (4) Disposition (allow/deny), (5) Timestamp. NGFW additions: (1) Application identification — identifies actual application regardless of port (BitTorrent on 443, Zoom on 80). (2) URL categories — classifies destinations by content type. (3) Anomaly detection — flags unusual traffic patterns. (4) User identity — associates traffic with authenticated users, not just IPs. NGFWs operate at Layer 7 vs. traditional Layer 3/4.

Application logs capture: successful/failed logins, data access, transactions, errors, and configuration changes within software. Windows: Event Viewer with named channels — System, Security, Application. Each event has a numeric Event ID (4625 = failed logon, 4648 = explicit credential use, 4720 = account created). Linux: /var/log directory — syslog (general), auth.log (authentication), apache2/access.log (web server), and application-specific files. Application logs are critical for detecting brute force attempts (repeated failed logins), privilege escalation, and access to sensitive data outside normal patterns.

OS security logs capture: authentication details (credential type, logon session IDs), account lockout events, file permission changes, audit policy changes, and privilege use. They are especially valuable for detecting: brute force attacks (mass Event ID 4625), privilege escalation (group membership changes), and covering tracks (audit log clearing — which itself generates an event). Why filter: OS security logs are extremely verbose — a busy server generates thousands of events per hour. Forwarding all events to SIEM without filtering overwhelms storage capacity, increases SIEM costs, and buries relevant events in noise. Filtering rules must be applied at the log collector to forward only security-relevant events.

IPS/IDS log fields: (1) Timestamp, (2) Attack classification (buffer overflow, SQL injection, port scan), (3) Source IP and port, (4) Destination IP and port, (5) Severity, (6) Action taken (for IPS: dropped or alerted). Correlation with firewall logs: An IPS alert for traffic that the firewall should have blocked indicates a firewall misconfiguration or rule gap — the traffic reached the IPS, which means the perimeter firewall allowed it through. Conversely, an IPS alert on already-blocked traffic may indicate an attacker probing from multiple source IPs. IPS and firewall logs together provide a more complete picture than either alone.

Switch logs: MAC address table changes, port state, VLAN events, spanning tree — detect rogue devices and MAC flooding. Router logs: routing table changes, interface state, ACL hits, BGP events — detect routing manipulation. WAP logs: client associations/disassociations, authentication events, channel changes — detect rogue clients, de-auth attacks, evil twin APs. VPN concentrator logs: user authentication, tunnel establishment/teardown, source IP of connections, per-session data volumes — detect credential stuffing against VPN, unusual geographic origin, large data transfers. All four are network infrastructure log sources distinct from host logs.

Metadata: data that describes other data — reveals who, when, where, how without requiring content analysis. Four security-relevant types: Email headers: sender, relay path with IPs and timestamps, authentication results (SPF/DKIM/DMARC) — traces phishing origin even when display name is spoofed. Mobile metadata: GPS coordinates in photos (EXIF), cell tower records, call detail records. File metadata: author, creation/modification dates, revision history — persists after sanitization attempts. Network metadata (NetFlow/IPFIX): source/dest IPs, ports, bytes transferred, flow duration without payload content. Metadata proves facts without content analysis.

SIEM (Security Information and Event Management): (1) Log aggregation — ingests logs from all sources into a central repository. (2) Normalization — converts disparate formats into a common data model for consistent querying. (3) Correlation rules — matches patterns across multiple sources (impossible travel, brute force followed by success). (4) Alerting — generates alerts with severity ratings when rules fire. (5) Retention — stores historical data for forensic investigation and compliance. Bonus: automated scheduled reports for compliance and management. The SIEM is only as good as the log sources feeding it and the rules applied to those logs.

Dashboard: real-time or near-real-time visualization of current security status — active alerts, live traffic volumes, recent authentication activity, top blocked IPs. Designed for operational monitoring by the security operations center. Shows what is happening NOW. Not designed for historical analysis — typically displays a short time window (last hour, last 24 hours). SIEM report: scheduled or ad-hoc analysis of historical log data over extended periods (last week, last quarter, last year). Used for compliance reporting, trend analysis, and forensic investigation. Both are necessary: dashboards for real-time operations, reports for management review and forensic work.

Vulnerability scan data shows: current attack surface (which systems have which CVEs), patch status, configuration weaknesses (default credentials, weak ciphers), and open ports. Correlation with IPS alerts: When an IPS alert fires for a specific CVE exploit attempt, the SIEM can check vulnerability scan data for the targeted system. If the target is already patched → lower priority (exploit unlikely to succeed). If the target is vulnerable → critical priority (active exploitation attempt on a vulnerable system). This cross-correlation prevents responders from treating all IPS alerts equally and enables risk-based prioritization. Trending scan data in SIEM over time shows whether patch management is improving or deteriorating.

Packet captures (pcap files, analyzed with Wireshark): record the complete content of network traffic at the deepest level, including full payload of every packet. What they reveal: exact data transmitted, protocols used (even encrypted protocol identification), malware C2 communication protocols, files transferred over the network, cleartext credentials. Why not pervasive: (1) Storage: a 10 Gbps link generates terabytes per day. (2) Legal/privacy: full packet capture of employee traffic may violate privacy laws and require legal authorization. (3) Encryption: encrypted payloads (TLS) are opaque without decryption. Typically deployed only at specific segments (DMZ, critical servers) rather than everywhere. NetFlow/IPFIX provides flow-level metadata at scale without these constraints.

Impossible travel detection: a SIEM correlation rule that fires when an account authenticates successfully from two geographically separated locations within a timeframe that cannot be achieved by physical travel. Example: successful login from New York at 14:00 and successful login from Tokyo at 14:10. Since no one can travel between NYC and Tokyo in 10 minutes, this indicates: credential compromise (attacker using stolen credentials) or prohibited account sharing. High fidelity because: legitimate impossible travel scenarios are extremely rare (VPN, always-on services sometimes create false positives, but these are identifiable). The rule crosses multiple log sources: VPN logs, Active Directory authentication logs, possibly firewall logs — making it hard to trigger accidentally. It is a strong indicator of account compromise.

Each log source provides a partial view with specific blind spots: Firewall logs: show perimeter connections but not post-connection activity. Endpoint logs: show host activity but not network context. IPS logs: detect known signatures but miss novel attacks. Application logs: show application events but no network path. Metadata: shows context but not content. Packet captures: show everything but are impractical at scale. SIEM correlation: only as good as the logs it ingests and its rules. Effective security monitoring requires multiple sources feeding a SIEM with correlation rules that connect events across sources. An attack exploiting a gap in one log source will be visible in another — but only if both sources are collected and correlated.