Logger Retention Policy, Devices, and Storage Groups

We're trying to stand up a SIEM offering and have run into a particular problem related to retention of customer audit logs.  We have a myriad of firewall devices sending their audit logs to one or more Connectors via an anycast address (so that the audit log gets delivered to the "closest" Connector).  We would like to be able to funnel audit logs from a particular event source (i.e., the firewall device) into one and only one Storage Group on the Logger.

WHen initially reading the Logger documentation, it appeared as though this was a trivial task--you just set up Devices, Device Groups, Storage Rules, and Storage Groups.  But I'm finding now that the "Device" is not the event source (the firewall), but the Connector that is sending the logs back to the Logger.

Is there an easy way to accomplish this objective?  I would think this is a relatively common use case, but I can't find any threads on the topic.


Derek Smith

  • I've run into this before as well.  While it would seem logical that the device is derived form the deviceAddress field it is, unfortunately, actually the source address of the connection to Logger from the connector or syslog server and so not something that you can just override in the connector for example. From the admin guide:

    The combination of a source IP address and a Logger receiver is called a device. As events are received, devices are automatically created for each IP/receiver pair. Devices can also be manually created, anticipating future traffic.

    If you do come up with a solution, I'd be interested to see it

  • Verified Answer

    Richard, I think we've come up with a solution to this problem.  Working with HP and reading through the documentation, we decided to expand the number of "devices" by adding additional Receivers on Logger, which allows us to create more devices.  On the ConnApps, we provisioned additional SmartConnectors to send to those receivers.  Each of these SmartConnectors are dedicated to a retention tier.  You also have to do work to ensure that specific customer devices are configured to send their logs to the appropriate SmartConnector. 

    It makes a lot of sense to do it this way because each of the SmartConnectors can have different aggregation and filtering policies applied to them as well.  Customer's who are paying for long-term retention will probably also be customers that want EVERY audit log retained, which means we can disable aggregation on the SmartConnectors that are dedicated for that storage tier.

    Hope this helps.