Log data analysis

In many cases, you can find evidence of an attack in the log messages of devices, systems, and applications. The ThreatLockDown log data analysis module receives logs through text files or Windows event logs. It can also directly receive logs via remote syslog, which is useful for firewalls and other such devices.

Additionally, the log data analysis module analyzes the log data received from agents. It performs decoding and rule matching on the received data to process it. You can then use this processed log data for threat detection, prevention, and active response.

The log collector module helps to meet the following PCI DSS requirement:

  • Requirement 10 - Log and Monitor All Access to System Components and Cardholder Data: This control requires that user activities, including those by employees, contractors, consultants, internal and external vendors, and other third parties are logged and monitored, and the log data stored for a specified period of time.

To help meet this requirement, the ThreatLockDown agent collects logs from the endpoints it is deployed on. The log analysis module also receives logs via syslog for network and other syslog-enabled devices. It decodes the logs received to extract relevant information from its fields. After that, it compares the extracted information to the ruleset to look for matches. When the extracted information matches a rule, ThreatLockDown generates an alert. Refer to the ruleset section for more information.

ThreatLockDown also holds logs of events that don't generate an alert. For this it uses its archive feature and the indexer long term storage. For more information on configuring log collection, see the Log data collection section.

Use cases

  • PCI DSS 10.2.2 requires that audit logs record the following details for each auditable event:

    • User identification.

    • Type of event.

    • Date and time.

    • Success and failure indication.

    • Origination of event.

    • Identity or name of affected data, system component, resource, or service (for example, name and protocol).

      The following are some ThreatLockDown rules that help achieve this requirement:

    • Rule 5710 - sshd: attempt to login using a non-existent user: This rule generates an alert when a non-existent user tries to log in to a system via SSH. The generated alert contains the information required by requirement 10.2.2 (user identification, type of event, date and time, success and failure indication, origination of event, and identity or name of affected data, system component, resource, or service). The screenshot below shows the alert generated on the dashboard:

    • Rule 5715 - sshd: authentication success: This rule generates an alert when a user successfully logs into a system via SSH. The generated alert contains the information required by requirement 10.2.2 (user identification, type of event, date and time, success and failure indication, origination of event, and identity or name of affected data, system component, resource, or service). The screenshot below shows the alert generated on the dashboard:

  • PCI DSS 10.5.1 requires that you retain audit log history for at least 12 months, with at least the most recent three months immediately available for analysis. You can achieve this by enabling ThreatLockDown log archives and configuring index management policies. To enable ThreatLockDown log archives, take the following steps:

    Enable archives monitoring in the ThreatLockDown indexer:

    1. Set <logall_json>yes</logall_json> in /var/ossec/etc/ossec.conf.

    2. Set archives: enabled to true in /etc/filebeat/filebeat.yml:

      archives:
enabled: true

    3. Restart Filebeat:

      # systemctl restart filebeat

    4. Restart the ThreatLockDown manager:

      # systemctl restart wazuh-manager

    5. Select ☰ > Indexer/dashboard management > Dashboards Management in the ThreatLockDown dashboard.

    6. Choose Index Patterns and select Create index pattern. Use wazuh-archives-* as the index pattern name.

    7. Select timestamp as the primary time field for use with the global time filter, then proceed to create the index pattern.

    8. Open the menu and select Discover under Explore. Events should be getting reported there.

  • PCI DSS requirement 10.4.1 requires to review the following audit logs at least once daily:

    • All security events.

    • Logs of all system components that store, process, or transmit cardholder data (CHD) and/or sensitive authentication data (SAD).

    • Logs of all critical system components.

    • Logs of all servers and system components that perform security functions (for example, network security controls, intrusion-detection systems/intrusion-prevention systems (IDS/IPS), and authentication servers).

    This requirement ensures analyzing logs for indicators of compromise at least once daily. The following are some ThreatLockDown rules that may help in achieving this requirement:

    • Rule 61138: New Windows Service Created. The analysis engine analyzes the Windows system logs to find out if a new service was created generating an alert from this rule.

    • Rule 31168: Shellshock attack detected. The analysis engine analyzes logs to find out about shellshock attacks from a WAF or web application generating an alert.