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 1 commit
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
28 changes: 17 additions & 11 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 Down Expand Up @@ -88,23 +88,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