IBM Support

QRadar®: How to create a sAN certificate for a TLS Syslog integration

How To


Summary

This doc helps you create a self-signed Subject Alternative Names (sAN) cert with a private key for devices such as Palo Alto Cortex XDR. This doc is intended as an example how it could work, as organizations have their own PKI requirements and standards, we're unable to give a "one-size-fits-all" example.

Objective

This article is not applicable for QRadar on Cloud (QRoC) consoles (not Data Gateways). QRoC consoles require Public CA signed certificates. 
The objective is to integrate Palo Alto Cortex XDR events.

Note: The events are currently not supported, so a Custom DSM needs to be created to parse events.
This certificate can either be:
  • A self-signed sAN certificate, or
  • A Public Root CA-signed certificate. You need to create a Certificate Signing Request (CSR), and the QRadar administrator has to action the signing (either by corporate internal CA or Public CA).
Note: The QRadar default "syslog-tls.cert" cannot be used - Cortex XDR currently refuses a cert where the Issuer and Subject are "*". This means that the "Generate Certificate" option in the Log Source Configuration is not going to work.
As not all QRadar users have a Public CA-signed certificate ready to be deployed, a self-signed certificate is a quick working solution.
Good to know: The PA Cortex XDR device sends events with two or more Source IP addresses.

Steps

  1. Log in as root or at least run "sudo su -" on the QRadar host where the event ingestion is be done (eventcollector/-processor or data gateway).
  2. Optional: Create a directory where you create the config file, CSR or cert, and key. (mkdir -pv /root/cortex_certs).
  3. Create a sancert.conf file with the information:
    [ req ]
    default_bits            = 2048  # RSA key size
    encrypt_key             = no  # Protect private key
    default_md              = sha256  # MD to use
    utf8                    = yes  # Input is UTF-8
    string_mask             = utf8only  # Emit UTF-8 strings
    prompt                  = no  # Prompt for DN
    distinguished_name      = server_dn  # DN template
    req_extensions          = server_reqext  # Desired extensions
    [ server_dn ]
    countryName             = XX  # ISO 3166
    stateOrProvinceName     = town/city
    localityName            = town/city
    organizationName        = Company
    organizationalUnitName  = Company
    commonName              = company.net  # Should match a SAN under alt_names
    emailAddress            = # Remove this line if you don't need it
    [ server_reqext ]
    basicConstraints        = CA:FALSE
    keyUsage                = critical,digitalSignature,keyEncipherment,keyAgreement
    extendedKeyUsage        = serverAuth,clientAuth
    subjectKeyIdentifier    = hash
    subjectAltName          = @alt_names
    [alt_names]
    DNS.1                   = company.net
    DNS.2                   = *.company.net
  4. Create the cert or CSR and key (use your own file names and expiry days if needed).
    Alternatively A or B:
    A) Certificate and private key: 
    openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout qroc_cortex_priv_key.pem -out qroc_cortex_selfsigned_cert.pem -config sancert.conf -extensions server_reqext

    B) CSR and private key: 
    openssl req -new -nodes -days 365 -newkey rsa:2048 -keyout qroc_cortex_priv_key.pem -out qroc_cortex_csr.pem -config sancert.conf -extensions server_reqext
    Submit the CSR to your internal or commercial certificate authority for signing, according to their instructions.
    The procedure might involve opening the CSR file and copying a block of encoded text that is contained between the BEGIN and END markers.
  5. Convert the private key from base64 PEM to DER:
    openssl pkcs8 -topk8 -inform PEM -outform DER -in qroc_cortex_priv_key.pem -out qroc_cortex_priv_key.der -nocrypt
    Note - the key needs to be unencrypted (-nocrypt).
  6. Place the cert and key in /opt/qradar/conf/trusted_certificates directory on the QRadar Event Collector or Data Gateway (QRoC).
  7. Log in to QRadar GUI, go to the Admin tab.
  8. Create a Log Source using either your own log source type for Cortex XDR events or at the minimum, a Universal DSM, using TLS Syslog as the protocol. 
    Example configuration:
    • Log source identifier: "cortexxdr" - This is the default Syslog header of the event payloads. 
    • TLS listen port: 6514 is the default port
    • Authentication mode: TLS
    • Certificate Type: PEM certificate and private key (for the lack of a PKCS12 certificate in this example)
    • Provided Server Certificate Path: the full path of the cert
    • Provided Private Key Path: the full path of the private key
    • Use As A Gateway Log Source: Disabled
      You can use this TLS Syslog log source as a "gateway," but in that case, you need to create an extra Syslog log source for the actual parsing of Cortex XDR events.
    • You can ignore the protocol test part for now and save the log source. (The test fails with "connection refused" until you have deployed the log source.)
    • Deploy the log source.
      image 8413
  9. You can test whether the certificate is being presented or not on the selected port:
    openssl s_client -connect localhost:6514 < /dev/null

    Example output (QRadar default certificate, shortened)
    CONNECTED(00000003)
    depth=0 CN = *, O = SyslogTLS_Server
    verify error:num=18:self signed certificate
    verify return:1
    depth=0 CN = *, O = SyslogTLS_Server
    verify return:1
    ---
    Certificate chain
     0 s:/CN=*/O=SyslogTLS_Server
       i:/CN=*/O=SyslogTLS_Server
    ---
    Server certificate
    -----BEGIN CERTIFICATE-----
    MIIDITCCAgmgAwIB...........
    -----END CERTIFICATE-----
    subject=/CN=*/O=SyslogTLS_Server
    issuer=/CN=*/O=SyslogTLS_Server
    .................
    
        Verify return code: 18 (self signed certificate)
    ---
    DONE
  10. Upload the same certificate to the Cortex XDR and run a "Test" from the Cortex XDR GUI.
  11. Check what the Source IPs are; Cortex XDR usually uses 2 IP addresses as Source IPs.
  12. Check QRadar, Log Activity for events using, for example, a "Source IP [Indexed], Equals any of, IP1 and IP2".
  13. The events are expected to show as "unknown" if you haven't created a Custom DSM in DSM Editor for your events.
    Reference: IBM Knowledge Center: DSM Editor overviewed

Document Location

Worldwide

[{"Line of Business":{"code":"LOB24","label":"Security Software"},"Business Unit":{"code":"BU059","label":"IBM Software w\/o TPS"},"Product":{"code":"SSBQAC","label":"IBM Security QRadar SIEM"},"ARM Category":[{"code":"a8m0z000000cwt0AAA","label":"Log Source"}],"ARM Case Number":"","Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"All Version(s)"}]

Document Information

Modified date:
25 July 2022

UID

ibm16415905