[RFC] Session Fields

[dainperkins]

New RFC for Session fields provided.

[ebeahan]

Thanks @dainperkins for writing this up!

Outside of the outstanding CHANGELOG question, I noticed a few minor editorial suggestions on my first read-through.

[ebeahan]

I took another editorial pass to clean up the formatting a bit more for reviewing.

[ebeahan]

@dainperkins I pushed a couple of changes to clean up the formatting a bit. No content changes 😄

[ebeahan]

Phase 0 (Strawperson) Criteria:

• Discuss with domain or subject matter experts the utility of these changes
• Discuss with ECS team whether these changes seem appropriate for ECS

[ebeahan]

Again thanks @dainperkins for submitting. I believe adding session as a top-level field set does address a current gap in ECS.

The documentation will need to be clear that this field set is intended for; I could see possible end-user confusion over whether session is intended for network session (which the client/server field sets are intended) vs. login sessions. I think there's also good opportunity with session to consider field reuse possibilities (e.g. nesting user).

[ebeahan]

Ping @webmat @MikePaquette @jamiehynds @jonathan-buttner @leehinman to get some ECS committee visibility and discussion started 😄

[bkimmel]

❔ This reads a little bit like a tautology ( "A session is something that is typically a session" ). Adding a more formal definition like "A session typically encompasses the data that a system uses to manage instances of authentication against user identities, roles, etc." might help the reader here.

[dainperkins]

Excellent suggestion - will work it in.

[dainperkins]

updated

These fields are used to track an entity's interaction with various assets, services, and applications in an enterprise.  Sessions will typically include a start event, often a login / authorization event performed locally or via network based mechanisms, and an end event indicating a logoff or session termination.  

When available, event start/end or duration fields should be populated, as well as iam, user, network, host, observer, process, source, destination, client, and server fields as appropriate to describe the specifics of the interaction.

[webmat]

Thanks Dain for opening this!

I think this is appropriate for ECS, which is the only criteria for a stage 0 proposal.

I haven't had time to pore over the RFC content in detail. I skimmed it quickly and I think we'll need to adjust a few things, but this can also be addressed in detail in the stage 1 PR as well.

I would like to merge this early to mid next week, so we can start the PR on the stage 1 proposal. One request before we merge, though:

• Could you merge master, and move the file to the new directory rfcs/text/ please? :-)

If you have time to adjust the following before then as well, great. Otherwise stage 1 PR could address those, I think:

• Mention more explicitly that this can apply to web user sessions, backed by cookies or other means, etc.
• Put the sample logs towards the end in code blocks, for readability. Example for the Meraki logs:

---

Example 1: Meraki

802.1x Logs (WLC) (EAP session start)

<134>1 1580551704.928047208 my_AP events type=8021x_eap_success radio='1' vap='2' client_mac='12:34:56:78:9A:BC' client_ip='192.168.1.100' identity='JohnDoe' aid='1687088497'

802.1x EAP De-association Message (EAP session end)

<134>1 1580551705.928047208 my_AP events type=8021x_deauth radio='1' vap='2' identity='JohnDoe' aid='1687088497'

You can use single backticks for single lines, and triple backticks for multi-line, depending on the situation.

[webmat]

Note for the future: we set this at the time we merge the RFC PR. No need to twiddle with it :-)

No action is needed, though.

[jonathan-buttner]

Sorry I've been MIA! We've been swamped with the 7.9 release. @epixa @webmat other than what Mat outlined is there anything else I can help with to get this merged and moved to stage 1?

There are a couple people within the security org that I'd like to chime in on this as we iterate on the exact fields we'll be adding to ECS. Is stage 1 the appropriate time to do that?

[webmat]

This is great, thanks for reaching out about the interest :-)

So Dain is the original author, but we can move to having multiple co-authors to get this moving faster. We're definitely looking forward to the Endpoint team's input on this.

For simplicity's sake, if the team wants to comment about this today, you're welcome to comment on this PR directly.

The bar for merging as stage 0 is already met (this is appropriate for ECS), so we'll merge as soon as the file is moved to the right directory.

After stage 0 is merged, you or someone from Endpoint could open the next PR to continue the process of fleshing this out. Also, seeing the interest from Endpoint, it sounds like the team would like to be the official sponsor for these fields? 👍

And to answer your question, yes stage 1 will be a great time to start fleshing out the list of fields we'll need for sessions :-)

[andrewvc]

Some thoughts from Uptime:

1. Having type and kind is confusing. More verbosity would help here. IMHO stick with one and add a qualifier
2. These sessions seem very network oriented, have you considered browser sessions and how they'd apply here?
3. It seems like adding the layer 7 protocol would make sense as well.

[dainperkins]

@andrewvc

1. Having type and kind is confusing. More verbosity would help here. IMHO stick with one and add a qualifier

Maybe using more discretely specific qualifiers would help (not sure what those are but I get the point)

2. These sessions seem very network oriented, have you considered browser sessions and how they'd apply here?

Definitely want to cover browser sessions, applications sessions (sql, etc), I just didn;t have any handy when I wrote the rfc

3. It seems like adding the layer 7 protocol would make sense as well.

Would be all set with e.g. existing ECS fields (network.protocol, etc.)

What do you think about:

Field	Description
session.type:	local, remote, network
session.authorization:	user, admin, service
session.scope:	system, virtual, application, wired, wireless, vpn
session.name	locally relevant name if available (e.g. HQ Client VPN, Win19-VDI, FIN-EXCEL-vApp)
session.id	session id provided by server or custom fingerprint

Network specifics would be covered by network, client/source, server/destination, application (web, etc) and/or host fields

Are there other session specific things that I don't have covered in other areas to cover APM requirements?

[dainperkins]

@webmat
Made a bunch of updates, added a text directory and moved the rfc md file there. I think I need an approval after the changes

[ebeahan]

Thanks @dainperkins, and ++ to all the great discussion from everyone as well.

We'll assign the RFC number, update the date, and merge this in for stage 0.

[webmat]

@andrewvc Yes the goal for capturing sessions in ECS is to be inclusive of all the various kinds of sessions. Hopefully we can define fields that are applicable to all kinds of sessions. If need be, we can have fields specific to some kinds of sessions as well.

I'm envisioning this supporting:

• physical user sessions at a desktop
• various kinds of network sessions, including browser sessions

We can continue refining this on subsequent stage PRs