Add event.tactic and event.technique fields

[MikePaquette]

To accommodate security analytics use cases, it is useful to be able to filter, aggregate, and visualize events by the tactics and techniques in use when the event was created. For example the MITRE ATT&CK framework provides a reference list of tactics and techniques.

If an event or alert is generated by a rule that was written to detect certain tactics or techniques, then those tactics and/or techniques would be populated in these fields.

This PR partially addresses questions raised in #113

[ruflin]

As these are very specific for the security analytics use case I'm starting to think we should group these somewhere outside of event?

[MikePaquette]

@ruflin that's certainly possible, for example we explored creating a threat.* object in #113 where they could exist. The argument for keeping them in the event.* space is that they'll fit in along with the other ECS categorization fields event.kind, event.category, event.type, and event.outcome...

Let me propose an alternative for consideration.

Anyone else have thoughts on this?

[ruflin]

Agree that some of the above could actually fit better under threat. Also thinking of outcome for example.

[MikePaquette]

@ruflin I think "outcome" will be used quite broadly across many events, including system (successful vs. failed calls), file (successful vs. failed access attempts), and security (successful vs. failed login attempts) events, so I would try to keep it in the common fields as event.outcome rather than moving it under a new threat.* object.

[ruflin]

What about the tactic and technique added here? Should go under threat?

[MikePaquette]

Yes, I think tactic and threat will fit better under a threat.* object.