This was causing bad anchor merge behavior. Basically, before this change, array sub-elements of an anchor node would get merged rather than overwritten when used, so:

macros:
  - &ecs-file
    category: file
    type: info

normalizations:
  - action: test
    ecs:
      <<: *ecs-file
      type: test

Would previously result in:

{
  ...
  "normalizations": [
    "action": "test",
    "ecs": {
      "category": ["file"],
      "type": ["info", "test"]
    }
  ]
}

rather than:

{
  ...
  "normalizations": [
    "action": "test",
    "ecs": {
      "category": ["file"],
      "type": ["test"]
    }
  ]
}

which is the intended (and to spec) result.

we're only explicit if something was a failure otherwise, unknown/success are implied based off of the context of the category/type

So, we still have a bunch of ECS normalization we can add for some of these audit types, but I figured I could do that in a subsequent PR since this is already a ton of changes

The thought is that only a process can actually make syscalls anyway--so if we have a syscall where we haven't normalized it to a behavior (i.e. create a file)--then just say it's "process info" with ECS: event.category: process, event.type: info

These two syscall normalizations were added

Non blocking
Would event.kind be held somewhere else? or maybe the caller of the library is responsible for that?

What do you think about having something about ECS categorization in the struct type? That might provide clues to the type of fields in the struct.

my initial thought is that it could be in the caller--namely because I'm pretty sure we're working only with event kinds--but then again would "anomaly" events actually be alert kinds? If so, or if we just want to be explicit, I can add kind in a follow-up PR.

For the second question, I'm not entirely sure I follow--do you meaning adding constant enums for the categorization values themselves? If so I'd almost prefer to do that in the ECS go generated code from the ECS repo itself (which ideally we'd be using here too--but we still need to add tags and formalize on things like omitempty, pointer usage, etc. before doing that).

I'm good with it being the callers responsibility, I just wanted to double check that we weren't missing one of the ECS categorization fields.

I was thinking the name of the type might be better as ECSCategorization or ECSCat or something like that, since it really just holds the categorization info, nothing else about ECS.

Enums would be awesome and I agree it would be good to do that work once in ECS repo.

non blocking

because "failure" is one of 3 constant values, it might be nice to use a constant for this.

ideally this would also be in an enum in the ECS generated go structures