Skip to content
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.

Sign up for GitHub

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

[RFC] Session RFC PR to move to Stage 2 (Draft) #935

Open
wants to merge 13 commits into
base: main
Choose a base branch
from
Open

[RFC] Session RFC PR to move to Stage 2 (Draft) #935

Changes from 2 commits
Commits
Show all changes
13 commits
Select commit Hold shift + click to select a range
d6714a0
Updated Session rfc (stage 2)
dainperkins Aug 17, 2020
4c2a21d
Updated Session RFC kind/type
dainperkins Aug 28, 2020
9d1e57d
Updated session kind and type
dainperkins Sep 14, 2020
57fc786
Unset the merge date. We'll set when stage 1 merges.
Oct 19, 2020
0721f80
Link to stage 1 RFC
Oct 19, 2020
16d1b9d
Space. The final frontier.
Oct 19, 2020
c8cb020
Move YML field descriptions to a file under 0004/ directory
Oct 19, 2020
983668c
Fix YAML format, try to make descriptions render well.
Oct 19, 2020
71e62aa
Try to reformat the examples...
Oct 19, 2020
c341ea3
event.category session
Oct 19, 2020
848fffd
Add a few contributors to the People section
Oct 19, 2020
69c11c7
It's stage 2, not stage 1
Oct 19, 2020
94aa976
Update rfcs/text/0004-session.md
dainperkins Feb 17, 2021
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
65 changes: 39 additions & 26 deletions rfcs/text/0004-session.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,8 +1,8 @@
# 0004: Session
<!--^ The ECS team will assign a unique, contiguous RFC number upon merging the initial stage of this RFC, taking care not to conflict with other RFCs.-->

- Stage: **0 (strawperson)** <!-- Update to reflect target stage -->
- Date: 7/30/2020 <!-- Update to reflect date of most recent stage advancement -->
- Stage: **2 (draft)** <!-- Update to reflect target stage -->
dainperkins marked this conversation as resolved.
Show resolved Hide resolved
- Date: 8/17/2020 <!-- Update to reflect date of most recent stage advancement -->
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ECS team will update to the date when PR is merged as stage 2.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We can also link the Stage 2 PR at the bottom now that the PR's opened.


<!--
Stage 0: Provide a high level summary of the premise of these changes. Briefly describe the nature, purpose, and impact of the changes. ~2-5 sentences.
Expand All @@ -13,11 +13,11 @@ This RFC calls for the addition of session fields to describe events related to

| Field | Description |
| ----- | ----------- |
|session.kind: | local, remote, network
|session.authorization: | user, admin, service
|session.type: | system, virtual, application, wired, wireless, vpn
|session.kind: | system, application, network
|session.type: | [ local, remote, virtual, wired, wireless, vpn ]
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

IMHO kind vs type is really hard to reason about / remember. type would be more clear if it was named connection_type.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I like the idea, tho my brain says "local isn't a connection!" but maybe thats ok.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think I've updated these a bit, was hoping to get some feedback before submitting updates. I'll try and get the revisions up in the near future

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sure, I would say that local is a connection, connecting to local host is a connection, just within a single kernel.

|session.authorization: | user, admin, service, access
Comment on lines +19 to +21
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This compact table is a great way to visualize all of these values together.

I have a few questions:

The value "access" appears to have been dropped out of the values mentioned in the YAML description. Was this intentional? If so, please remove it from here. If it was not intentional, please add it back in the new YAML file at rfcs/text/0004/session.yml

I initially thought there was an overlap with values session.kind: network and session.type: remote. When adjusting the YAML file for readability it occurred to me that session.kind: network was likely more to identify network level sessions, rather than anything that happens over a network. In other words, a web cookie-based session would not use session.kind: network, but session.kind: application. Am I understanding this correctly?

However within the different values for session.type, I do wonder if there's overlap. It seems like "wired", "wireless" and "vpn" would always be accompanied by value "remote". Is this also how you see this? Note that this is not necessarily a problem. "local" vs "remote" could be useful when plotted against one another, whereas "wired", "wireless" & "vpn" could be useful to break down the kinds of "remote" session types.

One final overlap concern: I do think session.kind: system and session.authorization: service are almost entirely overlapping, aren't they? Should we get rid of one of them, or am I misunderstanding a subtlety?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

One final overlap concern: I do think session.kind: system and session.authorization: service are almost entirely overlapping, aren't they? Should we get rid of one of them, or am I misunderstanding a subtlety?

I was trying to find discrete combinations that would uniquely identify logging into a system, and a service running with authentication/authorization included in the "session". It may be unnecessary (I'll look thru auditbeat service logs and see what they look like... could just be that a system service is not something that would typically be defined as a session (e.g. starting up a vpn connection on a pfsense linux firewall - presumably the vpn application logs would be sufficient)

The value "access" appears to have been dropped...

the revamp of the fields seems to lend itself more towards the entity being authorized - authentication would be a part of the overall session, but I don't think it makes sense as a specific session field. Basically the split becomes:

  • "user interactive session" (user logs in or connects to a service or application to use said service/app)
  • "admin interactive session"(user logs in to manage a service or application e.g. root, enable mode in cisco parlance)
  • "Network session" (user or system connects to a monitored network)

Not all of the type values will apply to every session.kind:
Session Kind:

  • System (full system access)
    • local (hands on keyboard)
    • remote (bash via ssh)
    • virtual (Citrix -virtual desktop)
  • Application
    • remote (e.g. web connection, smb share, ftp)
    • local (possible but I can't think of an example)
    • virtual (citrix published apps)
      -Network
    • wired (802.1x network session - e.g. time connected to the LAN)
    • wireless (802.1x network session - e.g. time connected to the WLAN)
    • vpn (user connects to vpn concentrator

I think this one could use some more input- I can see session.type having fixed single values (virtual implies remote), or using an array (vpn would be network & remote, published apps & citrix desktop would be virtual & remote, opening a virtualbox session locally could be local & virtual...)

Does that all make sense?

Wired & wireless however would typically not use remote as the session is for the local user or workstation directly connecting to the local network (as opposed to connecting to another entity over the network)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm actually wondering if virtual needs to be specifically identified... a "remote" "system" session will be telnet, ssh, rdp, or citrix... not sure the virtual type is necessary to split out rdp/citrix

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

And service as an authorization could also make sense for workstation based network access (802.1x cert auth), network to network vpn, etc...

|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
|session.id | session id provided by server or custom fingerprint of discrete identifiers



Expand All @@ -41,24 +41,30 @@ This RFC calls for the addition of session fields to describe events related to
level: extended
type: keyword
short: Kind of session
description: > Session kind can be local (console, on the keyboard), remote (ssh, vdi, web, ftp), or network (802.1x, wpa, NAC)
Additional fields will be dependent on the specifics of the session reported.
description: >
Session kind can be local (console, on the keyboard), remote (ssh, vdi, web, ftp), or network (802.1x, wpa, NAC)
Additional fields will be dependent on the specifics of the session reported.

example: network

- name: authorization
level: extended
type: keyword
description: Authorization scope of the session. Initial values will include general user level access (e.g. user vdi/vda, vpn, or web sessions, network access, etc), administrative sessions (root, VMWare Host access, router cli, etc.) or service (network to network VPN, non-user verified services sessions e.g. micro-service backend architectures).

example: user

- name: type
level: extended
type: Logical session type
description: Session type describes the interaction/access provided. Initial values include system (shell or desktop), virtual (VDI), application (web, ftp, etc.), wired (nac, 802.1x), wireless (wpa/.1x), or vpn (ipsec, ssl, etc). Note that actual aaa mechanism (system, domain, wpa, 802.1x) does not indicate a specific session type.
short: Type of session (array)
description: >
Session type describes the interaction/access provided. Initial values include system (shell or desktop), virtual (VDI), application (web, ftp, etc.), wired (nac, 802.1x), wireless (wpa/.1x), or vpn (ipsec, ssl, etc). Note that actual aaa mechanism (system, domain, wpa, 802.1x) does not indicate a specific session type.

example: wireless
normalize:
- array

- name: authorization
level: extended
type: keyword
description: >
Authorization scope of the session. Initial values will include general user level access (e.g. user vdi/vda, vpn, or web sessions, network access, etc), administrative sessions (root, VMWare Host access, router "enable" level cli, etc.) or service (network to network VPN, non-user verified services sessions e.g. micro-service backend architectures).

example: user

- name: name
level: extended
Expand All @@ -70,7 +76,8 @@ This RFC calls for the addition of session fields to describe events related to
- name: id
level: extended
type: Session id
description: The id field is meant to contain a locally significant identifier for the session as provided by the observer or host reporting the session. If no id is provided this field can remain blank, or a hash function similar to network.community_id can be used to discretely identify sessions from unique values.
description: >
The id field is meant to contain a locally significant identifier for the session as provided by the observer or host reporting the session. If no id is provided this field can remain blank, or a hash function similar to network.community_id can be used to discretely identify sessions from unique values.

example: 7635344
```
Expand All @@ -88,23 +95,29 @@ Stage 3: Add or update all remaining field definitions. The list should now be e

## Usage

Session fields are used to describe the sesison attributes of:
- Client VPN Sessions
- Network to Network VPN Sessions
- Network Access Sessions (NAC, WPA, EAP, etc.)
- Local or remote device login sessions (RDP, ICA, xWindows)
Session fields are used to describe and track a discrete grouping of interactions, typically bounded by
authentication or authorization events and tied to a specific user, application, or system component.

For example:
- Network Access Sessions (NAC or Wireless LAN)
- Local or remote device login sessions (tty, console, ssh, RDP, ICA, xWindows, etc.)
- VPN Sessions (network to network, or client to network)
- Local or remote device login sessions (console, tty, RDP, ICA, xWindows, ssh, etc.)
- Administrative sessions on infrastructure devices
- Administrative sessions on cloud or application management portals
- Applications sessions (e.g. sql server odbc session, application access session)
- Applications sessions (e.g. sql server odbc session, web cookie based session, application access session)
- Cloud API access sessions


## Source data
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For each of the log examples in the "Source data" section, could you include a breakdown of expected values for the session fields of each log event?

E.g. the ASA login could be something like

  • session.kind: network
  • session.authorization: admin
  • session.type: [remote]

Not sure if one of the values in the ASA example is a session name or session id, but if so, list those as well.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah - probably wouldn't be a bad idea to fill in everything in some additional example.json file(s)?

Source data expectations include:
- Wireless Lan Controllers
- Security appliances
- Security appliances (e.g. fw, waf)
- Network admission control devices
- Radius / tacacs servers
- Application server logs
- Radius / tacacs servers (802.1x EAP/PEAP aaa)
- Application server logs (FTP, MySQL)
- Web Server, WAF, or ADC logs (USer or cookie based web ession control)
- APM telemetry
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For our RUM agent, running on client websites tracking browsing sessions, I can only see us setting session.kind and session.id. Would love feedback from the RFC authors on whether this makes sense.

CC @jahtalab

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think the idea (only filling out relevant fields) makes total sense... tho in respect to this and the previous comment it makes me think I'm missing something that identifies a RUM type session (but then I also don't really know what other fields would be coming in that would make filtering results from a mixed index easy). Unauthenticated web sessions for instance would't need to use session.auth, but after a login could (along with user.name, etc.). I don't see that one as big a deal as e.g. network access logins (vpn, wireless, etc)

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

To add some context, the RUM sessions are not necessarily authenticated, even until they are complete, e.g. a user session for going through checkout.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@jahtalab do we have any notion of auth no? AFAIK we don't, and it's unlikely given the extreme variety of auth methods.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@andrewvc , We don't detect authentication per se, but there's a configuration for customers to add the user (username, id, ..) in the RUM agent. We can assume the user is authenticated (with some method) but it doesn't have to be.


Example 1: Meraki 802.1x Logs (WLC)
* EAP session start)
Expand Down