Forward Logs from Strata Logging Service
Learn how to forward logs from Strata Logging Service to an
external destination.
| Where Can I Use This? | What Do I Need? |
|---|
To meet your organization's legal compliance requirements and operational needs, you can forward
firewall logs stored in
Strata Logging Service to external destinations. For
example, you can forward logs using syslog to a SIEM for long term storage, SOC, or
internal audit obligations, and forward email notifications for critical events to an
email address. You can forward logs to the following
SIEMs:
- Exabeam
- Google Chronicle
- Microsoft Sentinel
- Splunk HTTP Event Collector (HEC)
When forwarding logs, Strata Logging Service ensures accurate log
representation and does not round down log values with long identifiers. Long
identifiers can be crucial to identify log records. If you use a third-party log
streaming solution as an intermediary to forward logs from Strata Logging Service, the volume of received logs can vary depending on the
log processing mechanism used by the third-party solution, including how the
solution handles long identifiers.
Strata Logging Service can forward logs in multiple formats: CSV, LEEF, CEF, JSON, or PARQUET.
For each instance of Strata Logging Service, you can forward logs to up to 200
syslog destinations. Use the following table to find more information about supported
log formats.
| Log Format | Where to find more information about the logs: | IETF Standard | Default Field Delimiter |
|---|
The
Strata Logging Service ensures secure communication with log receivers through
the following mechanisms:
- TLS 1.2 Encryption: All communications are encrypted using TLS 1.2, ensuring
data security during transmission.
- Java 8 default cipher suites: The
service uses Java 8 default cipher suites, with the exception of GCM ciphers,
which are not currently supported.
- Certificate Validation: To establish a secure connection, the Strata Logging Service requires that the log receiver provides a valid
certificate.
- Trusted Certification: The receiver's certificate must be signed by a
trusted root CA or a private CA.
- Chain of Trust: The receiver must present all certificates in the chain
of trust to successfully complete the TLS handshake and establish the
connection.
