Log Management practice questions

Set the log.level to error

Why it fails: This only affects logging output, not processing capacity.

Disable the Elasticsearch output plugin

Why it fails: Disabling output prevents log archival.

Change the time_zone parameter

Why it fails: Timezone affects metadata, not throughput.

wmic eventlog

Why it fails: WMIC is deprecated and not for subscription management.

winrm get config

Why it fails: This manages WinRM service configuration, not subscriptions.

gpresult /r

Why it fails: This shows Group Policy results, not log subscription status.

Enable the auditd service to generate audit records for all system calls and forward them to the SIEM.

Why it fails: Auditd provides detailed system call auditing but does not cryptographically sign or protect log entries from tampering. An attacker with root privileges could alter audit logs as well. This does not meet the requirement of cryptographic integrity verification from the point of generation.

Configure logrotate to compress and encrypt log files with GnuPG after rotation.

Why it fails: logrotate can compress and encrypt rotated files, but this only protects logs after rotation. It does not provide integrity verification for individual log entries or prevent tampering before rotation. An attacker could modify logs in real time before rotation occurs, and the encryption would not detect such changes.

Configure Rsyslog to sign each log message using a private key and include the signature in the message.

Why it fails: Rsyslog does not natively sign individual log messages with a private key and embed signatures. While TLS can protect transmission, it does not provide per-message cryptographic integrity at rest. This approach would require custom modules and is not a standard feature, making it unreliable for verifying logs after collection.

Event ID 4656 (A handle to an object was requested)

Why it fails: Event ID 4656 is generated when a handle to an object is requested, such as a file or registry key. While credential dumping may involve accessing the LSASS process, 4656 is not the primary event for detecting such access. It requires additional auditing settings and is not as directly indicative as other events specifically tied to LSASS access.

Event ID 4663 (An attempt was made to access an object)

Why it fails: Event ID 4663 records attempts to access objects and can be useful if object access auditing is enabled for the LSASS process. However, it is not the most direct indicator of credential dumping. It may generate a high volume of events and requires careful configuration to be effective, making it less prioritized than events specifically designed to detect suspicious LSASS access.

Event ID 4624 (An account was successfully logged on)

Why it fails: Event ID 4624 logs successful logon events and is useful for tracking access, but it does not directly indicate credential dumping. Mimikatz and similar tools may generate logon events, but these are common and not specific to credential theft. Focusing solely on 4624 would produce many false positives and miss the actual dumping activity.

Set the subscription to use the 'Minimize Bandwidth' delivery mode.

Why it fails: The 'Minimize Bandwidth' delivery mode compresses event data but does not affect the inclusion of computer name or user account. It is used to reduce network traffic, not to enrich events. This option would not ensure that the original computer name and user account are present in the forwarded events.

Configure the subscription to use the 'Normal' delivery mode and ensure the event log is set to include the user account.

Why it fails: The 'Normal' delivery mode is the default and does not control user account inclusion. User account information is part of the event data if the event itself contains it. However, this option does not guarantee that the user account is included; it depends on the event source. It is not a specific configuration to ensure the desired fields.

Enable the 'Include the computer name in the event' option in the subscription properties.

Why it fails: While Windows Event Forwarding inherently includes the computer name in the event metadata, there is no specific option called 'Include the computer name in the event' in the subscription properties. The computer name is automatically included as part of the event's system data. This option is a distractor because it references a non-existent setting.

Store logs in a flat file and use a cron job to periodically convert them to CSV.

Why it fails: Converting logs to CSV via a cron job is a batch process that introduces delay and is not suitable for real-time SIEM ingestion. CSV is a structured format, but the conversion is manual and error-prone, especially for complex log lines. It also does not provide the nested structure of JSON that SIEMs prefer. This approach is inefficient for continuous monitoring and lacks the immediacy required for SOC operations.

Enable debug-level logging in the application to generate more detailed messages.

Why it fails: Enabling debug-level logging increases the verbosity and volume of log messages but does not inherently structure them. The output remains in the application's original format, which may still be unstructured text. While more details can aid troubleshooting, it does not create parseable fields like JSON. Therefore, this method does not achieve structured logging and can actually exacerbate log management challenges by increasing noise.

Use a regular expression in the SIEM to extract fields at search time.

Why it fails: Using regular expressions at search time in the SIEM can extract fields on the fly, but it does not store logs in a structured format. The logs remain unstructured at rest, and parsing occurs during query, which can be resource-intensive and slow. For consistent and efficient analysis, logs should be structured at ingestion. This method is a workaround, not a solution for achieving structured logging from applications.

Run auditpol /set /category:"Logon/Logoff" /success:enable /failure:enable and auditpol /set /category:"Account Management" /success:enable /failure:enable on the server.

Why it fails: The auditpol command with category-level switches enables auditing at a coarse level, but in modern Windows the Advanced Audit Policy subcategories (such as Logon and Account Lockout) take precedence when configured via GPO. Running only category-level commands may be overridden by domain policy and is not the recommended way to guarantee the specific subcategory events needed here.

Increase the maximum size of the Security event log to 1 GB and set it to overwrite events as needed.

Why it fails: Increasing the log size and configuring overwrite behavior only affects retention and rotation of events that are already being generated; it does not cause failed logons, lockouts, or privilege-use events to be audited in the first place. Without enabling the corresponding audit subcategories, these events will never appear in the Security log for forwarding.

Install the Windows SIEM agent and configure it to read from the C:\Windows\System32\winevt\Logs folder.

Why it fails: The SIEM agent can only forward events that already exist in the event logs. Merely installing an agent and pointing it at the log folder does not enable the underlying audit policies, so the required 4625, 4740, and 4672 events would still not be generated. Auditing must be enabled separately at the policy level.

Archive all logs in a local text file format only

Why it fails: PCI-DSS requires retained logs to remain readable and available for forensic and audit review, not confined to a local text file. It is tempting because plain-text archives are portable, but the standard mandates centralised, tamper-resistant retention rather than a single local format.

Retain logs for exactly 30 days

Why it fails: PCI-DSS requires audit trail history retention of at least twelve months, with the most recent three months immediately available, so exactly 30 days fails. It is tempting because 30 days is a common operational window, but it satisfies neither the twelve-month nor the three-month accessibility requirement.

Delete logs after they are indexed in the SIEM

Why it fails: Deleting logs once indexed in the SIEM destroys the retained audit trail PCI-DSS requires for at least twelve months. It is tempting because SIEM indexing enables fast searching, yet the standard demands the original records persist independently of the analytics platform.

UDP

Why it fails: UDP provides no acknowledgement or retransmission, so the aggregator cannot confirm receipt of log datagrams; lost packets vanish silently. It is tempting because UDP's low overhead suits high-volume, loss-tolerant streams such as syslog over a trusted LAN, but delivery confirmation demands TCP's sequenced acknowledgements.

ICMP

Why it fails: ICMP is a network diagnostics protocol carrying error and control messages, not application log payloads, so it provides no delivery confirmation for log records. It suits connectivity testing such as ping; reliable log transmission requires a transport with acknowledgement, such as TCP-based syslog.

ARP

Why it fails: ARP resolves IPv4 addresses to MAC addresses on a local segment; it carries no payload transport and cannot move log data between collector and aggregator. It is tempting as a familiar Layer 2 protocol, yet it is the correct choice only when mapping an IP to a MAC before framing, never for reliable log delivery.

Simple Queue Service (SQS)

Why it fails: SQS is a message queue for decoupling application components; it does not collect or forward server logs to CloudWatch. It tempts because it ingests data from producers, but it is the correct choice for asynchronous message passing between distributed services, not for agent-based log streaming from an on-premises host.

Kinesis Firehose

Why it fails: Kinesis Firehose delivers streaming data to destinations such as S3, Redshift, or Splunk, but it does not run on-premises or forward logs directly into CloudWatch Logs. It tempts as a managed ingestion pipeline, yet it is the correct choice for buffering and loading high-volume streams into data stores, not host-based log shipping.

AWS Config

Why it fails: AWS Config records resource configuration changes and evaluates compliance, not log ingestion; it cannot receive streams from an on-premises server. It tempts because it is an AWS service with 'configuration' in its name, but it is the correct choice for tracking resource state and drift, not for forwarding logs to CloudWatch.

Utilizing SNMPv1 traps

Why it fails: SNMPv1 traps carry community strings in cleartext and provide no encryption or authentication, so log payloads are readable and forgeable in transit. SNMPv1 is tempting for lightweight device monitoring on trusted management networks. Syslog over TLS delivers the required confidentiality and integrity.

Encapsulating logs in cleartext UDP packets

Why it fails: Cleartext UDP exposes log contents to any observer on the path and offers no integrity checking, so credentials and event data travel readable. It is tempting for speed and low overhead on trusted internal links. TLS-encrypted transport such as syslog over TLS satisfies the confidentiality requirement instead.

Using standard port 514 without encryption

Why it fails: Port 514 is plain syslog, sending messages unencrypted and unauthenticated, so anyone capturing traffic reads the sensitive log data. It is tempting because it is the default, widely supported syslog port. Syslog over TLS on port 6514 provides the encryption and integrity this scenario demands.

Defining separate log paths for every individual IP address

Why it fails: Separate log paths keyed to individual IP addresses hardcode each device, so new or re-addressed devices fall outside the routing and hostname-based directories are never built. Per-IP paths suit small, fixed device sets. Dynamic hostname separation requires the ${HOST} macro in the destination path.

Configuring the global log_level to debug

Why it fails: log_level controls the verbosity of syslog-ng's own internal diagnostic messages, not destination file paths, so it cannot separate logs by hostname. Raising it to debug is tempting when troubleshooting parsing or routing problems, but directory separation needs a ${HOST} macro in the destination path.

Using hardcoded static path strings only

Why it fails: Hardcoded static paths write every device's logs to one fixed directory, so hostname-based separation never occurs. Static paths suit single-source or uniform-destination setups where all logs belong together. Department separation requires a macro such as ${HOST} inside the destination path template.

/var/log/messages

Why it fails: /var/log/messages is a log file that rsyslog writes to, not a configuration file logrotate reads. It is tempting because it holds the log data being rotated, but logrotate's retention and compression directives belong in /etc/logrotate.conf and its drop-in files under /etc/logrotate.d/.

/etc/rsyslog.conf

Why it fails: /etc/rsyslog.conf defines rsyslog's rules for routing and filtering messages to destinations, not logrotate's retention or compression directives. It is tempting because both tools govern logging, but rotation policy lives in /etc/logrotate.conf and /etc/logrotate.d/, which rsyslog.conf never supplies.

/etc/sysctl.conf

Why it fails: /etc/sysctl.conf holds kernel runtime parameters such as network and memory tuning; logrotate reads its retention and compression directives from /etc/logrotate.conf and the drop-in files under /etc/logrotate.d/. It is tempting because both are central Linux configuration files, but sysctl governs kernel behaviour, not log rotation schedules.

Manual data entry

Why it fails: Manual data entry cannot scale to continuous unstructured log volumes and introduces human error, so it fails to map fields to SIEM taxonomy reliably. It tempts when volumes are tiny or one-off, where hand-keying a few records is feasible, but production log ingestion demands automated parsing.

Disabling field mapping

Why it fails: Disabling field mapping leaves parsed values unattributed, so SIEM taxonomy fields remain empty and correlation cannot occur. It tempts as a troubleshooting step to isolate parser faults, but as a production technique it directly contradicts the requirement to map log fields to taxonomy.

Using a fixed-width parser

Why it fails: Fixed-width parsing splits each line by character position, so it cannot map variable-length unstructured log fields to taxonomy names. It tempts because fixed-width works well for mainframe or legacy records with consistent column layouts, but unstructured logs lack that positional regularity, defeating field extraction entirely.

End-user Workstation

Why it fails: An end-user workstation generates its own local events and forwards them onward; it does not receive and normalise logs from other nodes. It tempts because workstations are log sources, but the component aggregating and parsing data from many nodes is the collector.

Log Source

Why it fails: A log source is the origin device that generates events, such as a firewall or server, not the collector that receives and normalises them. It tempts because sources feed the pipeline, but the component performing reception and format normalisation is the log collector or agent.

Database Engine

Why it fails: The database engine stores and indexes processed events for querying; it receives already-normalised data rather than raw feeds from network nodes. It tempts as the storage tier, but normalisation and reception happen upstream, in the collector, before records reach the database.

Default login credentials for all devices

Why it fails: Default credentials are a vulnerability to eliminate, not a policy component; a robust log management policy specifies credential rotation, retention and integrity controls. Storing factory defaults invites unauthorised access and log tampering. Defaults belong in initial device provisioning, where they must be changed immediately, never in a security policy.

The salary of the SOC analyst

Why it fails: Analyst salary is a budgeting and HR matter, not a log management control, so it contributes nothing to log collection, retention, review or protection. It is tempting because staffing underpins SOC operations, but policy components address log sources, retention periods, access controls and monitoring procedures.

Storing logs on a local partition

Why it fails: A local partition shares the host's storage and administrative domain, so anyone compromising that host can alter the logs directly. It is tempting because it isolates logs from other data and aids performance, and would be correct where the requirement is simply separating log volumes from application volumes.

Clearing the logs daily

Why it fails: Deleting logs destroys the very records whose integrity you must prove, so tampering becomes undetectable rather than prevented. It is tempting as a retention or disk-space control, and would suit environments where logs are already shipped to immutable off-host storage and local copies are disposable.

Setting file permissions to read-only

Why it fails: Read-only permissions are enforced by the same host operating system that an attacker with root or administrator rights already controls, so they can be reset before editing. It is tempting as basic hardening, and would be the right control for protecting static configuration files rather than append-only audit records.

Increased disk space on the local server

Why it fails: Centralised logging frees local storage by moving retention off-box, but the question asks the primary benefit: aggregated, tamper-resistant correlation across hosts. Increased local disk space is tempting since local logs consume it, yet that is a side effect, not the core purpose.

Eliminating the need for a security policy

Why it fails: A logging server changes where records are stored and analysed; it cannot remove governance requirements, and policy still defines what is logged, retained and reviewed. Eliminating policy is tempting as reduced administrative effort, yet policy remains mandatory regardless of log architecture.

Faster network traffic speeds

Why it fails: Centralised logging consolidates events for correlation and retention; it does not alter link bandwidth or routing, so throughput stays governed by the underlying network. Faster traffic is tempting because off-box shipping adds overhead, yet that is a performance concern, not the primary benefit.

Office wallpaper settings

Why it fails: Office wallpaper settings record only cosmetic desktop configuration, containing no authentication, process or network telemetry, so they cannot reconstruct an intrusion timeline. The registry keys behind them are tempting because Group Policy troubleshooting genuinely uses them to confirm whether a policy applied to a user or device — a configuration-drift scenario, not forensic analysis.

Printer status logs

Why it fails: Printer status logs record consumable levels and job queues, offering no evidence of attacker activity. Such device telemetry would matter for print-fleet capacity planning, whereas intrusion forensics demands firewall, IDS/IPS, authentication and system event logs.

Mouse driver version logs

Why it fails: Mouse driver version logs capture peripheral hardware inventory, not security-relevant events. They suit endpoint asset management, but forensic reconstruction of an intrusion relies on network flow, firewall, authentication and host event logs that record attacker actions.

Deleting all incoming log metadata

Why it fails: Normalisation preserves and maps metadata into a common schema; deleting it destroys the fields normalisation exists to align. Stripping metadata is tempting as a way to reduce noise or storage, and it would be correct when purging sensitive or redundant attributes under a data-retention policy, not for schema alignment.

Increasing the network MTU size

Why it fails: MTU size governs frame payload at layer 2/3 and has no bearing on parsing or mapping log fields to a common schema. Raising MTU is tempting when logs are dropped or fragmented in transit, and it would be correct if the problem were truncated packets rather than inconsistent field formats.

Running a brute-force attack on the log file

Why it fails: Brute-forcing a log file guesses credentials against authentication data; it neither parses nor reformats log records into a common schema. It is tempting because brute-force tooling is a recognised security activity, and it would be the right approach when auditing weak passwords rather than normalising heterogeneous log formats.