Netapp audit event ecs mapping considerations
See original GitHub issueI’m in the process of migrating our NetApp audit events to ECS. Found a place for every field, except for the event where a file or directory is renamed.
It seems file.target_path
exists, but the doc says it’s meant for symlik targets, so for now I created file.path_new
.
Example:
{
"_index": "netapp-002-2019.01.29",
"_type": "doc",
"_id": "rqIDmmgB6pwhRqiLJ4Yx",
"_version": 1,
"_score": null,
"_source": {
"event.category": "Object renamed/moved",
"@version": "1",
"netapp.svm": "svm_002",
"file.path_new": "(vol_br01);/Data/Administratie/Balie/A. Nieuwe structuur Onthaal & balie/3. BESTELLINGEN/Economaat (Staples)/Staples 2018/2018",
"user.name": "bochan",
"@timestamp": "2019-01-29T14:28:44.253Z",
"client.ip": "1.54.50.149",
"client.domain": "MYDOMAIN",
"file.inode": "Nieuwe map",
"event.action": "Renamed,Moved",
"event.id": 9999,
"type": "netapp-audit",
"netapp.volume": "vol_br01",
"user.id": "S-1-5-21-171585296-3921855-1598175747-73842",
"file.path": "(vol_br01);/Data/Administratie/Balie/A. Nieuwe structuur Onthaal & balie/3. BESTELLINGEN/Economaat (Staples)/Staples 2018/Nieuwe map",
"event.created": "2019-01-29T14:33:48",
"file.type": "dir",
"observer.hostname": "oobserver-server"
},
"fields": {
"@timestamp": [
"2019-01-29T14:28:44.253Z"
],
"event.created": [
"2019-01-29T14:33:48.000Z"
]
}
}
So can we reuse file.target_path
to place renamed file names, or is there room for somethijng like file.path_new
? The NetApp audit events are inserted with a custom ps1 script we wrote to parse the evtx files generated by our NetApp.
I’m also wondering about event.id
, as the ecs docs say it should be unique? But the NetApp audit events can be any of 4 Winodws eventlog event id’s, 4656
, 4659
, 4660
or 9999
. Where will WIndows eventlog event id’s be saved in ecs?
Found 2 NetApp specific fields for which I created
netapp.svm
netapp.volume
Issue Analytics
- State:
- Created 5 years ago
- Comments:10 (10 by maintainers)
Top GitHub Comments
Yeah I’ve found another source that will help me make sense of what’s in there as well.
Although it’s looking like the imminent “ECS update” will not tackle this. The deep event shaping should not be happening in the agent itself (especially not dealing with gray areas like this). Because any improvement to the event shaping now translate to a full rollout of Winlogbeat again. Not great 😉
So the “ECS update” will more likely set the stage to send straigthforward Windows Log events that can then be shaped up with Ingest Node (as Filebeat modules do). Although the infrastructure for that is not yet in place…
Found it => https://github.com/elastic/beats/pull/10333
When I find some time I’ll try to have a look at what’s going on there.