From e93a924fc44a3d131b4cc8c260f737b64c7aaff7 Mon Sep 17 00:00:00 2001
From: Mark Hopkin <mark.hopkin@elastic.co>
Date: Wed, 18 Jun 2025 14:06:22 +0100
Subject: [PATCH 1/3] Add user is privileged RFC

---
 rfcs/text/0000-user-is-privileged.md | 81 ++++++++++++++++++++++++++++
 1 file changed, 81 insertions(+)
 create mode 100644 rfcs/text/0000-user-is-privileged.md

diff --git a/rfcs/text/0000-user-is-privileged.md b/rfcs/text/0000-user-is-privileged.md
new file mode 100644
index 000000000..113f68590
--- /dev/null
+++ b/rfcs/text/0000-user-is-privileged.md
@@ -0,0 +1,81 @@
+# 0000: Add user.is_privileged boolean field
+
+- Stage: **0 (strawperson)** 
+- Date: **TBD** 
+
+This RFC proposes adding a new boolean field, `user.is_privileged`. It will explicitly flag when a user has elevated or administrative rights such as ability to grant permissions, perform `sudo`, or manage IAM roles—so analysts can more easily filter, alert on, and correlate privileged‐user activity without custom parsing.
+
+## Fields
+
+```yaml
+- name: user.is_privileged
+  type: boolean
+  level: extended
+  description: >
+    True if the user associated with the event has elevated or administrative privileges,
+    such as membership in a `sudo` or `Administrators` group, use of `sudo`, or assignment
+    of owner/admin roles in cloud IAM.
+  example: true
+```
+
+## Usage
+
+Treating privileged status as a first-class field (vs. a tag) lets Kibana’s Entity Store resolve the current boolean value without extra parsing.
+
+Analysts will often want to perform more focused monitoring on privileged users, having it as a field in ECS will simplify this querying, e.g 
+
+```kql
+event.category:authentication and user.is_privileged:true
+```
+
+## Source data
+
+The entity centric integrations such as okta entity analytics and Entra ID entity analytics could populate this field, linux and windows integrations could also annotate command executions with this.
+
+## Scope of impact
+
+<!--
+Stage 2: Identifies scope of impact of changes. Are breaking changes required? Should deprecation strategies be adopted? Will significant refactoring be involved? Break the impact down into:
+ * Ingestion mechanisms (e.g. beats/logstash)
+ * Usage mechanisms (e.g. Kibana applications, detections)
+ * ECS project (e.g. docs, tooling)
+The goal here is to research and understand the impact of these changes on users in the community and development teams across Elastic. 2-5 sentences each.
+-->
+
+## Concerns
+
+- Cross-platform consistency: what counts as “privileged”?
+<!--
+Stage 1: Identify potential concerns, implementation challenges, or complexity. Spend some time on this. Play devil's advocate. Try to identify the sort of non-obvious challenges that tend to surface later. The goal here is to surface risks early, allow everyone the time to work through them, and ultimately document resolution for posterity's sake.
+-->
+
+<!--
+Stage 2: Document new concerns or resolutions to previously listed concerns. It's not critical that all concerns have resolutions at this point, but it would be helpful if resolutions were taking shape for the most significant concerns.
+-->
+
+<!--
+Stage 3: Document resolutions for all existing concerns. Any new concerns should be documented along with their resolution. The goal here is to eliminate risk of churn and instability by ensuring all concerns have been addressed.
+-->
+
+## People
+
+The following are the people that consulted on the contents of this RFC.
+
+* @hop-dev | author
+* @jaredburgettelastic | co-author
+* @MikePaquette | SME
+
+
+
+## References
+
+<!-- Insert any links appropriate to this RFC in this section. -->
+
+### RFC Pull Requests
+
+* Stage 0: https://github.com/elastic/ecs/pull/NNN
+
+<!--
+* Stage 1: https://github.com/elastic/ecs/pull/NNN
+...
+-->

From d47fca0a167ce9338dc170441a80786daf334242 Mon Sep 17 00:00:00 2001
From: Mark Hopkin <mark.hopkin@elastic.co>
Date: Wed, 18 Jun 2025 14:13:09 +0100
Subject: [PATCH 2/3] Add link to PR

---
 rfcs/text/0000-user-is-privileged.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/rfcs/text/0000-user-is-privileged.md b/rfcs/text/0000-user-is-privileged.md
index 113f68590..c38688d96 100644
--- a/rfcs/text/0000-user-is-privileged.md
+++ b/rfcs/text/0000-user-is-privileged.md
@@ -73,7 +73,7 @@ The following are the people that consulted on the contents of this RFC.
 
 ### RFC Pull Requests
 
-* Stage 0: https://github.com/elastic/ecs/pull/NNN
+* Stage 0: https://github.com/elastic/ecs/pull/2493
 
 <!--
 * Stage 1: https://github.com/elastic/ecs/pull/NNN

From fa5d8c0139127acd6d58d0d2bc92ff7270be2e45 Mon Sep 17 00:00:00 2001
From: Michael Wolf <michael.wolf@elastic.co>
Date: Mon, 23 Jun 2025 09:35:59 -0700
Subject: [PATCH 3/3] Change RFC number to 0051

---
 ...0-user-is-privileged.md => 0051-user-is-privileged.md} | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)
 rename rfcs/text/{0000-user-is-privileged.md => 0051-user-is-privileged.md} (96%)

diff --git a/rfcs/text/0000-user-is-privileged.md b/rfcs/text/0051-user-is-privileged.md
similarity index 96%
rename from rfcs/text/0000-user-is-privileged.md
rename to rfcs/text/0051-user-is-privileged.md
index c38688d96..878898a08 100644
--- a/rfcs/text/0000-user-is-privileged.md
+++ b/rfcs/text/0051-user-is-privileged.md
@@ -1,7 +1,7 @@
-# 0000: Add user.is_privileged boolean field
+# 0051: Add user.is_privileged boolean field
 
-- Stage: **0 (strawperson)** 
-- Date: **TBD** 
+- Stage: **0 (strawperson)**
+- Date: **2025-06-23**
 
 This RFC proposes adding a new boolean field, `user.is_privileged`. It will explicitly flag when a user has elevated or administrative rights such as ability to grant permissions, perform `sudo`, or manage IAM roles—so analysts can more easily filter, alert on, and correlate privileged‐user activity without custom parsing.
 
@@ -22,7 +22,7 @@ This RFC proposes adding a new boolean field, `user.is_privileged`. It will expl
 
 Treating privileged status as a first-class field (vs. a tag) lets Kibana’s Entity Store resolve the current boolean value without extra parsing.
 
-Analysts will often want to perform more focused monitoring on privileged users, having it as a field in ECS will simplify this querying, e.g 
+Analysts will often want to perform more focused monitoring on privileged users, having it as a field in ECS will simplify this querying, e.g
 
 ```kql
 event.category:authentication and user.is_privileged:true