Balabit - config.xml audit policy (site 2)

category: solutionz · date: 2018-12-31 · updated: 2026-10-03 · author: LALA

Balabit SCB Solution · Config document · referenced from Audit trails: encryption and replay

note<CERTIFICATE: removed> and [removed sensitive data] are not configuration: the appliance removed the private key when it exported the file, and the certificates were replaced by placeholders for this write-up. Which certificate stood in which group cannot be read from it any more.

The <pol_audit> element of the site 2 cluster's exported configuration: the audit policy default, which all eight connections of that cluster reference. It encrypts every audit trail to six certificate groups of one certificate each, timestamps it and signs it with one certificate and private key.

Item	Value
File	`config.xml` from a support bundle of the site 2 cluster `dc2-s-xblb001`, 2018-09-17
Firmware at the time	5.0.6
Element	`<pol_audit>`, complete
Referenced by	`<audit idref="id058"/>` in each of the eight connections, from `PARTNER1_SSH_JumpServer` to `PARTNER4_RDP_JumpServer`
Related	`<timestamping choice="local"/>` and `<signing_interval>30</signing_interval>` in the protocol options of the same file
Site 1 counterpart	Default audit policy (site 1), one encryption certificate

The file

xml

    <pol_audit>
      <audit id="id058" name="default">
        <encryption enabled="yes">
          <certificate_groups>
            <certificate_group>
              <certificate><CERTIFICATE: removed></certificate>
            </certificate_group>
            <certificate_group>
              <certificate><CERTIFICATE: removed></certificate>
            </certificate_group>
            <certificate_group>
              <certificate><CERTIFICATE: removed></certificate>
            </certificate_group>
            <certificate_group>
              <certificate><CERTIFICATE: removed></certificate>
            </certificate_group>
            <certificate_group>
              <certificate><CERTIFICATE: removed></certificate>
            </certificate_group>
            <certificate_group>
              <certificate><CERTIFICATE: removed></certificate>
            </certificate_group>
          </certificate_groups>
          <upstream_encryption enabled="no"/>
        </encryption>
        <timestamping enabled="yes"/>
        <signing enabled="yes">
          <certificate><CERTIFICATE: removed></certificate>
          <private_key type="rsa">[removed sensitive data]</private_key>
        </signing>
      </audit>
    </pol_audit>

Element	What it means
`<audit id="id058" name="default">`	the built-in policy, edited; `id058` is a shortened object id
`<certificate_groups>` with six `<certificate_group>`	six encryption certificates. As I understand the SCB's audit policy, the trail can be opened with the private key of any one group, and several certificates inside one group would all be needed (the way four-eyes decryption is built). Here every group holds one certificate
six groups	my XCA notes list six encryption keys for site 2: `SCB-AUDIT-ENCRYPT-DC2` and one for each of admin01, admin05, admin07, admin08 and admin09. The count matches; the certificates themselves are gone from the export, so the match is my inference
`<upstream_encryption enabled="no"/>`	the upstream direction is not encrypted with separate certificates, as in site 1
`<timestamping enabled="yes"/>`	timestamps are added; the protocol options choose the local TSA
`<signing enabled="yes">`	the certificate and the private key of the signing pair, `SCB-AUDIT-SIGN-DC2` per my key notes; the private key is on the appliance

The decryption how-to of the same cluster opens a partner 4 trail with one auditor's private key, which fits the reading above: one key of the six was enough.

Checked against One Identity Safeguard for Privileged Sessions 9.0

As built	Today
Six certificate groups of one certificate each	as I read it, what SPS 9.0 calls "Encrypt separately with multiple certificates"; a policy can have up to 8 lines of certificate pairs, and "Encrypt jointly with two certificates" is the four-eyes variant
`<upstream_encryption enabled="no"/>`	the security checklist recommends a separate certificate for the upstream traffic, so that RDP login passwords are not readable with the ordinary key
`<signing enabled="yes">` with an XCA certificate	the signing certificate must now have the extended key usage "Sign (downloadable) executable code"

The current documentation describes encryption to several certificates separately or jointly, which fits the reading of the six groups above; it does not describe the XML.