Introduction
This article will provide information about Logsign's data collection structures and the analysis of these logs.
Log Collection Structures
Logsign offers its users different types of structures for collecting logs, including pollers, netflow, leaf, and syslog structures.
Windows can collect logs using pollers or syslog from a logging source. The preference for this structure generally varies according to the EPS status of the source within the organization or Logsign's hardware usage planning.
Syslog Structure
Many security products or different agents support sending their existing logs using the syslog protocol.
You can receive logs sent from UDP port 514 or TCP port 515 with Logsign's syslog collector service.
Netflow Structure
You can obtain flow logs of products such as firewalls or switches with netflow.
Netflow V5 (2056), Netflow V9 (2055), IPFIX(2055), SFlow (6343).
Logsign LEAF Structure
Organizations that want to collect data from distributed locations or lighten the load on the center can collect logs with Logsign collector.
Poller Structure
Logsign can collect logs from sources using user identity verification and default protocols available in systems with its own services.
WMI
Windows can obtain system logs displayed in the EventViewer of a logging source using Microsoft Windows' WMI protocol with a WMI query. (Security, Application, System, Powershell, Sysmon, FileServer, etc.)
SFTP
Linux can obtain logs stored in files using a secure connection with the ssh protocol from a logging source. (Nginx, Apache, Auditd, Zimbra, etc.)
SMB
Windows can obtain logs written to a file in roles in a logging source with the SMBSHARE file-sharing protocol. (Exchange OWA, MessageTracing, IIS, DNS, DHCP)
API
You can collect logs with the API service generally supported by security products or cloud technologies.
(Office 365, Office 365 Management, G Suite, VMware Vcenter, ForcePoint, Blue Coat, JDBC {PostgreSQL, etc.}, Sophos XDR, Sentinel One, TINA, CloudFlare, Netskope, Acronis Cyber Cloud, FSecure WithSecure, Malwarebytes Nebula)
MSSQL
You can obtain audit logs, table, or view row logs from Microsoft SQL databases. The Poller MSSQL service stores responses as logs by sending Select queries to the database.
ORACLE
You can obtain table and view logs from Oracle databases. The Oracle database stores responses as logs by sending SQL queries.
FILEORBIS
You can obtain audit logs supported by some file server products.
GTB
You can obtain audit logs supported by some file server products.
Analysis
We can analyze logs in the user interface shortly after log source integration. After integration, it should be checked whether the desired logs are received from the log source. Even if your source sends logs, logs sent without high-level auditing will not provide functional logs in critical situations.
After source integration, the types of logs coming to the system with EventMap.Type should be checked; EventMap.Context will provide information about the content of log types that come with it. The presence of Not Set in these columns means there is a mismatch in the parsing process, and there may have been a problem with the parsing process. If Not Set logs are important to us, we can open a registration for custom plugins or plugin support with Logsign.
For example, in the case of adding a firewall source, log types such as Session and Connection should be displayed.
You need to check the logs of the rules (policies) in the Firewall resources. You can control it with Rule.Name or Policy.ID.
In another example, you need to check the channel information in the LogFile column in the Windows source to see if logs such as Security, PowerShell, etc. are coming.
It is important to check the event ID of the important logs with queries.
EventSource.IP:"10.10.0.13" Event.VendorID:("4624" OR "4625" OR "4104" OR "4688")