[Enhancement] [Cisco ISE] Make enhancement in connector with best practices implementation - #4694
Conversation
…r to the convert and date processors
|
Pinging @elastic/security-external-integrations (Team:Security-External Integrations) |
🚀 Benchmarks reportTo see the full report comment with |
🌐 Coverage report
|
P1llus
left a comment
There was a problem hiding this comment.
Some great enhancements here, some small nitpicks, mostly the same thing over and over again that might need to change a bit.
| - trim: | ||
| field: event.original | ||
| ignore_failure: true |
There was a problem hiding this comment.
Event original fields should never have any changes done to it, it should always be the raw field, please remove the processor.
| ctx.event.category = eventCategory; | ||
| - grok: | ||
| field: cisco_ise.log.message.description | ||
| if: ctx.cisco_ise?.log?.message?.description != null && ctx.cisco_ise.log.message.description != '' |
There was a problem hiding this comment.
Why does this have to be grok? Can we not simply rename description to event.action if the field is not null?
There was a problem hiding this comment.
Hi @P1llus, There are two sections of the message, that are separated by a colon. We have extracted only the value before the colon in the message, as the first section of the message gives a high-level overview of the action performed. Moreover, the message can be very long and we don't think keeping the whole message as event.action is appropriate. Therefore, we opted to extract only the part before the : to be the event.action.
ex: message --> "Administrator-Login: Administrator authentication succeeded" and event.action --> "administrator-login"
| field: error.message | ||
| value: '{{{_ingest.on_failure_message}}}' | ||
| - grok: | ||
| field: cisco_ise.log.message.description |
| value: '{{{_ingest.on_failure_message}}}' | ||
| - grok: | ||
| field: cisco_ise.log.message.description | ||
| if: ctx.cisco_ise?.log?.message?.description != null && ctx.cisco_ise.log.message.description != '' |
| ctx.event.action = ctx?.cisco_ise?.log?.message?.description?.splitOnToken(":")[0]?.toLowerCase(); | ||
| - grok: | ||
| field: cisco_ise.log.message.description | ||
| if: ctx.cisco_ise?.log?.message?.description != null && ctx.cisco_ise.log.message.description != '' |
| field: cisco_ise.log.message.description | ||
| value: "RADIUS: An Access-Request MUST contain at least a NAS-IP-Address NAS-IPv6-Address, or a NAS-Identifier; Continue processing" | ||
| if: ctx?.cisco_ise?.log?.message?.code == "11015" | ||
| value: 'RADIUS: An Access-Request MUST contain at least a NAS-IP-Address NAS-IPv6-Address, or a NAS-Identifier; Continue processing' |
There was a problem hiding this comment.
Why would we need to set the description manually here?
There was a problem hiding this comment.
We manually set the message for this specific message code, "11015," because it has multiple commas: "RADIUS: An Access-Request MUST contain at least a NAS-IP-Address, NAS-IPv6-Address, or a NAS-Identifier; Continue processing." If we do not set it manually, it will result in an inappropriate mapping in the KV processor, because in all the other messages, we get an end of the message with " ," . Moreover, we split the message using it. Therefore, we skip that message in the grok and manually set the value of the message field.
| - grok: | ||
| field: cisco_ise.log.message.description | ||
| if: ctx.cisco_ise?.log?.message?.description != null && ctx.cisco_ise.log.message.description != '' | ||
| patterns: |
| - grok: | ||
| field: cisco_ise.log.message.description | ||
| if: ctx.cisco_ise?.log?.message?.description != null && ctx.cisco_ise.log.message.description != '' | ||
| patterns: |
| - name: Cisco ISE | ||
| title: Cisco_ISE logs | ||
| description: Collect cisco_ise logs | ||
| description: Collect cisco_ise logs. |
There was a problem hiding this comment.
Should be Collect Cisco ISE logs.
|
Package cisco_ise - 1.4.0 containing this change is available at https://epr.elastic.co/search?package=cisco_ise |
…ctices implementation (elastic#4694) * Update Aggregation visualizations to Lens, Add an on_failure processor to the convert and date processors * Update changelog entry * Changes as per review comments
Type of change
What does this PR do?
Make enhancement in Cisco ISE connector with listed best practices.
Checklist
changelog.ymlfile.How to test this PR locally
Related issues
Screenshots