Q: How can Identity Panel logs be extracted for ingestion to a SEIM?
A: Identity Panel log data is available and ingestible.
Best Practice is to use the Identity Panel Reporting Engine to transform the data into an ingestible format, since the underlying data sources are both likely more verbose and deeper structured than required for ingestion into a SIEM (where focus should be on meeting the standard W5 audit history requirements - Who, What, Where, When & Why).
Specific data feeds for consideration may include:
- Web requests – all Identity Panel web requests are stored in a report/api accessible fashion for 30 days. You can use a report to fetch all requests, or just POST requests, or requests that interact with certain endpoints, e.g. /settings
- Service Form History – you could fetch all requests made against Service Panel. This data is retained up to your request data retention policy.
- Workflow History – you could fetch all workflows executed against target systems by Identity Panel. This data is retained up to your history data retention policy.
- Version History – you could fetch all settings changes made within Identity Panel, including who made them and what changed. This data is retained indefinitely.
- Time traveler history – you could fetch all identity changes registered by time traveler. This data is retained up to your general data retention policy.
Item #1 through #4 have sample reports available in Identity Panel Report Library on Box (course A821) and linked directly above, but #5 would require a custom report.
Report options
- Reports may be downloaded in any of the following formats:
- JSON
- XML
- CSV (tab delimited)
- Reports may be downloaded on a schedule or extracted via API requests.
-
Option A (simplest):
Indirect integration via a regular SIEM schedule (e.g. hourly) that downloads reports to a secure file share for ingestion. -
Option B (more complicated):
Direct integration by configuring the SIEM to fetch reports via calls to the Identity Panel REST API for reports. -
Option C (more complicated still, and not particularly recommended):
Direct integration by configuring the SIEM to target non-reporting API endpoints with dedicated API calls for each data type to be fetched.
-
Option A (simplest):
- For options B and C where calls (e.g. via script) are to be made to the Identity Panel Reporting API directly, a service account must be configured on the SEIM side for either:
- SCRAM-SHA512 authentication, or
- Basic authentication (disabled by default), which if configured and enabled should only be implemented with IP address origin constraints in place.
Comments
0 comments
Please sign in to leave a comment.