FIELDS column. Before building dashboards or alerts, promote those attributes into real columns by publishing a shaped dataset. Every dashboard card and monitor then shares one definition.
Shape and publish a dataset
The attributes the collector produced are addressable atFIELDS.logs.attributes. Bracket notation is required because the keys contain a dot.
1
In Observe, open a worksheet and select your datastream, for example
futurex-hsm-syslog.2
Open the OPAL editor and enter the following:
3
Run the query and confirm the six new columns are populated.
4
From the query menu, select Create new dataset, name it (for example
Futurex HSM Audit Events), select [ Next ], then [ Publish ].filter not is_null(hsm_device) line matters more than it looks. It discards any record whose envelope did not parse, and it also excludes historical records ingested before a parsing change. Without it, older rows appear in dashboards with every column empty.
hsm_raw carries the unmodified syslog datagram. Keep it. It lets you reclassify historical events after you add a new pattern, and it is the evidence an auditor will ask for.Build the dashboard
Create a dashboard, then add cards that query the published dataset. For time-series cards, usetimechart rather than the point-and-click aggregation builder. timechart buckets explicitly, so the result always has a clean time axis and one series per group.
Give time-series cards enough height. A card only a couple of rows tall has no room for an axis once the legend is drawn, and the plot area renders empty even though the query returned data.
Create monitors
Use the Count monitor type for all four alerts below. Each one queries the published dataset and filters byhsm_event_type.
To create each one:
1
Select New monitor, then choose Count.
2
Select the published dataset as the monitor query input.
3
Open the OPAL editor and enter the filter for that monitor. Leave it empty for the log-delivery monitor.
4
Under Alerting rules, set the comparison, the threshold, and the window.
5
Name the monitor, then select [ Save changes ].
Why these four
- Authentication failure burst uses a threshold rather than any-single-failure, because one mistyped password is not an incident. Two failures inside ten minutes is.
- Account lockout fires on a single event. The appliance only emits it after repeated failures, so it is already the summary of an attack pattern and needs no threshold of its own.
- Configuration change covers changes to device settings, including a change to the syslog forwarding target itself. That last one is worth watching: it is how someone would redirect the audit trail.
- Log delivery stopped is the one alert most integrations forget. Because forwarding is UDP with no acknowledgement, a broken path produces silence, not an error. Without this alert, the audit trail can stop and nothing reports it.
Tune thresholds against the observed baseline
An HSM in service is never quiet. Client applications log in on a schedule, which produces a steady stream ofauth_success and identity_update events, and appliance clock synchronization produces recurring time_change events, roughly every ten minutes in the tested environment.
Two consequences:
- The log-delivery monitor works precisely because the baseline is never zero. Set its window comfortably longer than the longest gap you observe between background events, then confirm the monitor does not fire during normal operation.
- Do not include
time_changein the configuration-change monitor. It is routine automation, and grouping it with real configuration changes makes that alert fire continuously and get muted, which defeats its purpose.
other. A rise there means the appliance is emitting a message shape the classification rules do not cover yet, which is most likely after a firmware upgrade.