Worfklow for Dynatrace#278
Conversation
|
fixed DCO. |
Signed-off-by: ibm-app-crest <ibm-app-upload@crestdata.ai> Signed-off-by: ebasso <ebasso@ebasso.net>
Signed-off-by: ibm-app-crest <ibm-app-upload@crestdata.ai> Signed-off-by: ebasso <ebasso@ebasso.net>
Signed-off-by: Bahdan Bakunovich <bahdan.bakunovich@orca.security> Signed-off-by: ebasso <ebasso@ebasso.net>
Signed-off-by: ebasso <ebasso@ebasso.net>
Signed-off-by: ebasso <ebasso@ebasso.net>
Signed-off-by: ebasso <ebasso@ebasso.net>
Signed-off-by: ebasso <ebasso@ebasso.net>
Signed-off-by: ebasso <ebasso@ebasso.net>
ChrisCollinsIBM
left a comment
ChrisCollinsIBM
left a comment
There was a problem hiding this comment.
My apologies for the delay in reviewing this, not sure how I missed it!
I've added some comments below, let me know if you'd like to address them before we merge this, or if you're ok with this going in as a sort of POC-style submission.
Thanks for contributing!
|
|
||
| <!-- Fetch the audit logs from Dynatrace --> | ||
| <CallEndpoint url="https://${/host}/api/v2/auditlogs" method="GET" savePath="/get_audit_logs"> | ||
| <QueryParameter name="from" value="${fromTime}" /> |
There was a problem hiding this comment.
This style of fixed interval time querying (last hour, last minute, last day, etc) is great for a POC of getting data but generally isn't suitable for production ingestion of data.
If the system doing the polling is ever down (patching, outage, etc) then you will definitely end up missing records even if polling every 5 minutes.
We can still merge this into the repo as an example of how you can get data in though, but it would need some refining into a sliding window for the time query, likely with the "from" time being a value that is greater than the timestamp of the last event retrieved (possible plus one millisecond, or one second depending on the API granularity).
| <!-- | ||
| Dynatrace Audit Logs API - QRadar Integration (Universal Cloud REST API) | ||
| --> | ||
| <Workflow name="DynatraceAuditLogs" version="1.0" xmlns="http://qradar.ibm.com/UniversalCloudRESTAPI/Workflow/V1"> |
There was a problem hiding this comment.
| <Workflow name="DynatraceAuditLogs" version="1.0" xmlns="http://qradar.ibm.com/UniversalCloudRESTAPI/Workflow/V1"> | |
| <Workflow name="DynatraceAuditLogs" version="1.0" xmlns="http://qradar.ibm.com/UniversalCloudRESTAPI/Workflow/V2_1"> |
Updating this and the parameters file to V2_1 instead of V1 will bring you up-to-date on the latest schema, and allow to to omit the source tag in the PostEvent call later so that end users can use whatever Log Source Identifier they like instead of having to use the ${host} value as currently configured.
| <!-- Process each audit log entry --> | ||
| <Log type="INFO" message="${/dynatrace_audit/logPrefix} - Processing audit log entry with ID: ${/current_audit_log/id}" /> | ||
| <!-- Post each audit log entry to QRadar --> | ||
| <PostEvent path="/current_audit_log" source="${/host}" /> |
There was a problem hiding this comment.
Updating to the V2_1 schema will allow you to drop the source tag below making end user configuration easier.
| <PostEvent path="/current_audit_log" source="${/host}" /> | |
| <PostEvent path="/current_audit_log" /> |
| @@ -0,0 +1,6 @@ | |||
| <?xml version="1.0" encoding="UTF-8" ?> | |||
| <WorkflowParameterValues xmlns="http://qradar.ibm.com/UniversalCloudRESTAPI/WorkflowParameterValues/V1"> | |||
There was a problem hiding this comment.
| <WorkflowParameterValues xmlns="http://qradar.ibm.com/UniversalCloudRESTAPI/WorkflowParameterValues/V1"> | |
| <WorkflowParameterValues xmlns="http://qradar.ibm.com/UniversalCloudRESTAPI/WorkflowParameterValues/V2_1"> |
Explained in more detail below: https://github.com/IBM/IBM-QRadar-Universal-Cloud-REST-API/pull/278/changes#r3095346056
ChrisCollinsIBM
added
the
workflow-submission
3 participants
This a workflow that get Audit Logs from Dynatrace and send to IBM QRadar