-
Notifications
You must be signed in to change notification settings - Fork 452
[symantec_endpoint_security] Event mapping improvements #13671
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[symantec_endpoint_security] Event mapping improvements #13671
Conversation
Pinging @elastic/security-service-integrations (Team:Security-Service Integrations) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How were these field removals/final inclusions chosen?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I included the ones that were mentioned in the request, plus some others that looked like they might be good to use in a query: ClientMachine, Reason, StartTime, State, SubjectDomain, User, Version.
description: Parse Windows Event data and store it in the same fields as the winlog integration does | ||
field: ses.data | ||
target_field: winlog.event_data | ||
if: ctx.ses?.type_id == '8015' && ctx.ses?.data instanceof String && ctx.ses.data.length() > 0 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ctx.ses?.type_id == '8015' && ctx.ses.data instanceof String && ctx.ses.data.length() > 0
- set: | ||
field: winlog.event_id | ||
copy_from: ses.ref_event | ||
if: ctx.ses?.type_id == '8015' && ctx.ses?.ref_event != null |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ctx.ses?.type_id == '8015' && ctx.ses.ref_event != null
field: file.hash.sha256 | ||
copy_from: ses.file.sha2 | ||
tag: set_file_hash_sha256_from_file_sha2 | ||
if: ctx.ses?.file?.sha2 != null && ctx.ses.file.sha2 != '' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
instanceof String
?
field: process.hash.sha256 | ||
copy_from: ses.process.file.sha2 | ||
tag: set_file_hash_sha256_from_process_file_sha2 | ||
if: ctx.ses?.process?.file?.sha2 != null && ctx.ses.process.file.sha2 != '' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
instanceof String
?
- _ingest._value.sub_technique_name | ||
tag: remove_custom_duplicate_fields_from_ses_attacks | ||
ignore_missing: true | ||
if: ctx.tags?.contains('preserve_duplicate_custom_fields') != true |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Isn't it the case that this condition must be true here given that it must have been true to run the foreach
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Correct. At the time I was thinking it's better to repeat the condition in case parts are moved around, but that doesn't actually make much sense here. I've removed it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM after conflicts are resolved.
Agree with the adjustments and the wont-do list in the description. Is it worth filing a follow-up for ses.edr_enriched_data.rule_description
-> message
?
…at elastic-package now generates.
…t "symantec_endpoint_security".
…CS fields. Specifically: ses.actor.file.folder -> file.directory ses.actor.file.original_name -> file.name ses.actor.user.sid -> user.id ses.actor.user.sid -> related.user
This follows the existing mapping of ses.process.file.name to file.name.
- Map `ses.reg_value.path` to `registry.path`. - Change mapping of `ses.reg_value.data` from to `registry.value` to `registry.data.bytes`. - Map `ses.reg_value.name` to `registry.value` (which is defined in ECS as "Name of the value written"). - Map `ses.reg_value_result.data` to `registry.data.bytes`.
6da5dff
to
2239113
Compare
Thanks. Seems like a good one to leave out since it's not in the documented fields, but I'll double check with the requestor and do a follow-up if it does make sense. |
🚀 Benchmarks reportTo see the full report comment with |
|
💚 Build Succeeded
History
|
Package symantec_endpoint_security - 1.11.0 containing this change is available at https://epr.elastic.co/package/symantec_endpoint_security/1.11.0/ |
Proposed commit message
Discussion
Can be reviewed commit-by-commit.
Suggested mappings done with adjustments:
Suggestion:
ses.actor.file.folder
->file.path
Done as
ses.actor.file.folder
->file.directory
to match ECS.Suggestion:
ses.cybox.files.folder
->file.path
Done as
ses.cybox.files.folder
->file.directory
to match ECS.Suggestion:
ses.file.folder
->file.path
Done as
ses.file.folder
->file.directory
to match ECS.Suggestion:
ses.connection.url.host
->url.original
Done as
ses.connection.url.host
->url.domain
to match ECS.Suggestion:
ses.connection.url.domain_name
->url.domain
Done as
ses.connection.url.host
->url.domain
to use the Symantec-documented URL field.Suggestion:
ses.process.file.original_name
->process.name
Done as
ses.process.file.original_name
->file.name
(as was already done forses.process.file.name
).Suggestion:
ses.reg_value_result.data
->registry.data.strings
Done as
ses.reg_value_result.data
->registry.data.bytes
because the sample value is base64, so it belongs in.bytes
not.strings
.Suggestion:
ses.reg_value.name
->registry.value
Done. Also changed prevous mapping
ses.reg_value.data
->registry.value
, to instead go toregistry.data.bytes
.Suggestion:
ses.product_data.bpe_description
(from JSON) ->threat.enrichments.indicator.description
(ormessage
)Done. Now
ses.product_data
is parsed if JSON, andmessage
if empty is set toses.product_data.bpe_description
if present.Suggested mappings not done:
Suggestion:
ses.cybox.files.product_name
->file.name
Not done because
product_name
doesn’t seem to be a file name with extension. Thename
field exists and is mapped to ECS’sfile.name
.Suggestion:
ses.connection.dst_name
->related.host
Not done. Should already be done by the processor with the tag
append_related_host_from_connection_dst_name
.Suggestion:
ses.edr_enriched_data.rule_description
->message
Not done. We don’t have
edr_enriched_data
as a defined field, and our sample data doesn’t have it. According to the Symantec documentation, all the given event types all have a recommendedmessage
field, which is mapped fromses.message
tomessage
. None of them have a documented field withenriched
in the name. I’d like to understand why these events aren’t gettingmessage
(ses.message
) populated. Ifses.edr_enriched_data.rule_description
is a good fallback source for amessage
value, I’d at least like to have some sample data that shows that.Suggestion:
ses.data
->message
Not done. I don’t think
message
is the right field for this, sincemessage
is expected to be human-readable rather than structured data. Everything will be decoded underwinlog.event_data.*
, so I’m not sure that duplicating it undermessage
(as well asses.data
) has any utility.Checklist
changelog.yml
file.Related issues