From 3ba9f6a54484bd92fea32902d823cbdfda1e20cd Mon Sep 17 00:00:00 2001
From: Ryland Herrick <ryalnd@gmail.com>
Date: Mon, 18 Sep 2023 21:35:31 -0500
Subject: [PATCH 01/10] Stage 2 Risk Extensions RFC

* Adds Source Data example
* Adds Scope of Impact section
* Updates Concerns section
---
 rfcs/text/0042-risk-score-extensions.md | 136 ++++++++++++++++++++----
 1 file changed, 114 insertions(+), 22 deletions(-)

diff --git a/rfcs/text/0042-risk-score-extensions.md b/rfcs/text/0042-risk-score-extensions.md
index 4446807c4..edfd9bf00 100644
--- a/rfcs/text/0042-risk-score-extensions.md
+++ b/rfcs/text/0042-risk-score-extensions.md
@@ -65,10 +65,6 @@ Beyond the per-category explanations, these fields' purpose is to provide more i
 * `notes`
   * Miscellaneous text field intended to provide more details that cannot be presented in the other fields.
 
-<!--
-Stage 1: Describe at a high level how this change affects fields. Include new or updated yml field definitions for all of the essential fields in this draft. While not exhaustive, the fields documented here should be comprehensive enough to deeply evaluate the technical considerations of this change. The goal here is to validate the technical details for all essential fields and to provide a basis for adding experimental field definitions to the schema. Use GitHub code blocks with yml syntax formatting, and add them to the corresponding RFC folder.
--->
-
 <!--
 Stage 2: Add or update all remaining field definitions. The list should now be exhaustive. The goal here is to validate the technical details of all remaining fields and to provide a basis for releasing these field definitions as beta in the schema. Use GitHub code blocks with yml syntax formatting, and add them to the corresponding RFC folder.
 -->
@@ -81,9 +77,107 @@ We intend to leverage these new fields as part of the new implementation of the
 
 The new Risk Engine will initially use Detection Engine Alerts as inputs to its scoring mechanism. However, we intend also to allow ingestion from the other Risk Categories described here, provided that they conform to the appropriate schema. Said schema is outside of the scope of this RFC, but based on the current implementation all we will need are a `score` field and a `category` field in order to ingest any arbitrary document.
 
-<!--
-Stage 2: Included a real world example source document. Ideally this example comes from the source(s) identified in stage 1. If not, it should replace them. The goal here is to validate the utility of these field changes in the context of a real world example. Format with the source name as a ### header and the example document in a GitHub code block with json formatting, or if on the larger side, add them to the corresponding RFC folder.
--->
+### Detection Engine Alert
+The following is an example alert from Kibana's detection engine. This alert would contribute to a user risk score for `Arturo_Haley`.
+
+```json
+{
+  "kibana.alert.start": "2023-04-11T20:18:15.816Z",
+  "kibana.alert.last_detected": "2023-04-11T20:18:15.816Z",
+  "kibana.version": "8.7.0",
+  "kibana.alert.rule.parameters": {
+    "description": "2",
+    "risk_score": 21,
+    "severity": "low",
+    "license": "",
+    "author": [],
+    "false_positives": [],
+    "from": "now-360s",
+    "rule_id": "d5496711-5f25-4fbf-a05a-4c708157fc7f",
+    "max_signals": 100,
+    "risk_score_mapping": [],
+    "severity_mapping": [],
+    "threat": [],
+    "to": "now",
+    "references": [],
+    "version": 3,
+    "exceptions_list": [],
+    "immutable": false,
+    "related_integrations": [],
+    "required_fields": [],
+    "setup": "",
+    "type": "query",
+    "language": "kuery",
+    "index": ["my*"],
+    "query": "*",
+    "filters": []
+  },
+  "kibana.alert.rule.category": "Custom Query Rule",
+  "kibana.alert.rule.consumer": "siem",
+  "kibana.alert.rule.execution.uuid": "dda06037-a804-4217-93b6-778a2f58dc1a",
+  "kibana.alert.rule.name": "1",
+  "kibana.alert.rule.producer": "siem",
+  "kibana.alert.rule.rule_type_id": "siem.queryRule",
+  "kibana.alert.rule.uuid": "8d7edef8-ae41-4b6e-aec9-783540a5ffb8",
+  "kibana.space_ids": ["default"],
+  "kibana.alert.rule.tags": [],
+  "@timestamp": 1691056730499,
+  "host": {
+    "name": "antique-leek.org",
+    "os": {
+      "full": "server"
+    }
+  },
+  "user": {
+    "name": "Arturo_Haley"
+  },
+  "event.kind": "signal",
+  "kibana.alert.original_time": "2023-04-11T20:17:14.851Z",
+  "kibana.alert.ancestors": [
+    {
+      "id": "8TD3cYcB1hicTK_CdP--",
+      "type": "event",
+      "index": "my-index",
+      "depth": 0
+    }
+  ],
+  "kibana.alert.status": "active",
+  "kibana.alert.workflow_status": "open",
+  "kibana.alert.depth": 1,
+  "kibana.alert.reason": "event on Host 4 created low alert 1.",
+  "kibana.alert.severity": "low",
+  "kibana.alert.risk_score": 21,
+  "kibana.alert.rule.actions": [],
+  "kibana.alert.rule.author": [],
+  "kibana.alert.rule.created_at": "2023-04-11T20:15:52.473Z",
+  "kibana.alert.rule.created_by": "elastic",
+  "kibana.alert.rule.description": "2",
+  "kibana.alert.rule.enabled": true,
+  "kibana.alert.rule.exceptions_list": [],
+  "kibana.alert.rule.false_positives": [],
+  "kibana.alert.rule.from": "now-360s",
+  "kibana.alert.rule.immutable": false,
+  "kibana.alert.rule.interval": "5m",
+  "kibana.alert.rule.indices": ["my*"],
+  "kibana.alert.rule.license": "",
+  "kibana.alert.rule.max_signals": 100,
+  "kibana.alert.rule.references": [],
+  "kibana.alert.rule.risk_score_mapping": [],
+  "kibana.alert.rule.rule_id": "cc066b08-b4d2-4e74-81cb-3cda5aaa612d",
+  "kibana.alert.rule.severity_mapping": [],
+  "kibana.alert.rule.threat": [],
+  "kibana.alert.rule.to": "now",
+  "kibana.alert.rule.type": "query",
+  "kibana.alert.rule.updated_at": "2023-04-11T20:18:11.024Z",
+  "kibana.alert.rule.updated_by": "elastic",
+  "kibana.alert.rule.version": 3,
+  "kibana.alert.rule.meta.from": "1m",
+  "kibana.alert.rule.meta.kibana_siem_app_url": "http://localhost:5601/app/security",
+  "kibana.alert.rule.risk_score": 21,
+  "kibana.alert.rule.severity": "low",
+  "kibana.alert.uuid": "856934e4-6d10-487e-9997-a9757b3f4927"
+}
+```
 
 <!--
 Stage 3: Add more real world example source documents so we have at least 2 total, but ideally 3. Format as described in stage 2.
@@ -91,13 +185,14 @@ Stage 3: Add more real world example source documents so we have at least 2 tota
 
 ## 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.
--->
+As these proposed fields are currently employed by the entity analytics risk engine, there are no first-party adoption/deprecation concerns. Additionally, since these fields are purely additive with respect to the existing risk fields, there are no migration/deprecation concerns.
+
+* Ingestion mechanisms
+  * While not officially supported, any systems that are currently ingesting risk documents (as originally introduced in RFC 31) _may_ need to be updated to support these additional fields.
+* Usage mechanisms (e.g. Kibana applications, detections)
+  * Kibana's usage of these fields is being developed by the Entity Analytics team, mainly leveraging them to build novel UI features for Risk Explainability.
+* ECS project (e.g. docs, tooling)
+  * There are no novel field types/mechanisms presented here.
 
 ## Concerns
 
@@ -105,16 +200,12 @@ There are two broad concerns at this stage:
 
 1. Category fields introducing a new "ordered" pattern
   * Rather than having either an array of objects, or an explicit `nested` field type, both of which allow an arbitrary number of items, we're instead opting to add 10 explicit fields (five explicit categories, each with two fields) under the _assumption_ that we won't extend the number of categories further. We have a bit of wiggle room (i.e. six categories, 12 fields wouldn't be out of question), but this is not a scalable solution if we need a large number of categories. However, that is only a potential future issue, and we can likely reevaluate and address it if/when it arises.
+  * RESOLUTION: we've decided to stick with this approach, for now.
 2. Mapping of `inputs` as a simple `object`
   * The biggest motivation for this choice is to avoid the performance/storage/syntax complexities that come with a `nested` mapping, but we also don't have any feature requirements that would currently necessitate `inputs` being `nested`.
-
-<!--
-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.
--->
+  * RESOLUTION: we've decided to stick with the simple, non-`nested` mapping for now. This decision is reinforced by the fact that these fields are used for the _explanation_ of a risk score, and it is unlikely that they will be useful in searches.
+3. Lack of user feedback
+  * Since these fields have been developed in an unreleased kibana feature, we have not had the opportunity to e.g. release a Technical Preview in order to garner user adoption and feedback. Lack of community engagement on these fields is likely the biggest risk, at this point.
 
 <!--
 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.
@@ -141,6 +232,7 @@ The following are the people that consulted on the contents of this RFC.
 
 * Stage 0: https://github.com/elastic/ecs/pull/2232
 * Stage 1: https://github.com/elastic/ecs/pull/2236
+* Stage 2: https://github.com/elastic/ecs/pull/2276
 
 <!--
 * Stage 1: https://github.com/elastic/ecs/pull/NNN

From 65447a6084d2151ab7ad44f314410661f77d9072 Mon Sep 17 00:00:00 2001
From: Ryland Herrick <ryalnd@gmail.com>
Date: Thu, 28 Sep 2023 16:41:10 -0500
Subject: [PATCH 02/10] Update rfcs/text/0042-risk-score-extensions.md

Co-authored-by: Eric Beahan <ebeahan@gmail.com>
---
 rfcs/text/0042-risk-score-extensions.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/rfcs/text/0042-risk-score-extensions.md b/rfcs/text/0042-risk-score-extensions.md
index edfd9bf00..ee3d72839 100644
--- a/rfcs/text/0042-risk-score-extensions.md
+++ b/rfcs/text/0042-risk-score-extensions.md
@@ -196,7 +196,7 @@ As these proposed fields are currently employed by the entity analytics risk eng
 
 ## Concerns
 
-There are two broad concerns at this stage:
+There are three broad concerns at this stage:
 
 1. Category fields introducing a new "ordered" pattern
   * Rather than having either an array of objects, or an explicit `nested` field type, both of which allow an arbitrary number of items, we're instead opting to add 10 explicit fields (five explicit categories, each with two fields) under the _assumption_ that we won't extend the number of categories further. We have a bit of wiggle room (i.e. six categories, 12 fields wouldn't be out of question), but this is not a scalable solution if we need a large number of categories. However, that is only a potential future issue, and we can likely reevaluate and address it if/when it arises.

From 6fc01863462f449762482a4237cb2a321f4a3e49 Mon Sep 17 00:00:00 2001
From: Ryland Herrick <ryalnd@gmail.com>
Date: Thu, 26 Oct 2023 13:21:46 -0500
Subject: [PATCH 03/10] Replace Alert document with Risk Score document

I misunderstood the "source data" section; a risk score document is what
actually shows the proposed fields being used.
---
 rfcs/text/0042-risk-score-extensions.md | 132 +++++++-----------------
 1 file changed, 37 insertions(+), 95 deletions(-)

diff --git a/rfcs/text/0042-risk-score-extensions.md b/rfcs/text/0042-risk-score-extensions.md
index ee3d72839..c13123fc1 100644
--- a/rfcs/text/0042-risk-score-extensions.md
+++ b/rfcs/text/0042-risk-score-extensions.md
@@ -77,105 +77,47 @@ We intend to leverage these new fields as part of the new implementation of the
 
 The new Risk Engine will initially use Detection Engine Alerts as inputs to its scoring mechanism. However, we intend also to allow ingestion from the other Risk Categories described here, provided that they conform to the appropriate schema. Said schema is outside of the scope of this RFC, but based on the current implementation all we will need are a `score` field and a `category` field in order to ingest any arbitrary document.
 
-### Detection Engine Alert
-The following is an example alert from Kibana's detection engine. This alert would contribute to a user risk score for `Arturo_Haley`.
+### Risk Score Document
+The following is an example risk score generated from Detection Engine Alerts, corresponding to the entity `host.name: 'siem-kibana'`
 
 ```json
 {
-  "kibana.alert.start": "2023-04-11T20:18:15.816Z",
-  "kibana.alert.last_detected": "2023-04-11T20:18:15.816Z",
-  "kibana.version": "8.7.0",
-  "kibana.alert.rule.parameters": {
-    "description": "2",
-    "risk_score": 21,
-    "severity": "low",
-    "license": "",
-    "author": [],
-    "false_positives": [],
-    "from": "now-360s",
-    "rule_id": "d5496711-5f25-4fbf-a05a-4c708157fc7f",
-    "max_signals": 100,
-    "risk_score_mapping": [],
-    "severity_mapping": [],
-    "threat": [],
-    "to": "now",
-    "references": [],
-    "version": 3,
-    "exceptions_list": [],
-    "immutable": false,
-    "related_integrations": [],
-    "required_fields": [],
-    "setup": "",
-    "type": "query",
-    "language": "kuery",
-    "index": ["my*"],
-    "query": "*",
-    "filters": []
-  },
-  "kibana.alert.rule.category": "Custom Query Rule",
-  "kibana.alert.rule.consumer": "siem",
-  "kibana.alert.rule.execution.uuid": "dda06037-a804-4217-93b6-778a2f58dc1a",
-  "kibana.alert.rule.name": "1",
-  "kibana.alert.rule.producer": "siem",
-  "kibana.alert.rule.rule_type_id": "siem.queryRule",
-  "kibana.alert.rule.uuid": "8d7edef8-ae41-4b6e-aec9-783540a5ffb8",
-  "kibana.space_ids": ["default"],
-  "kibana.alert.rule.tags": [],
-  "@timestamp": 1691056730499,
-  "host": {
-    "name": "antique-leek.org",
-    "os": {
-      "full": "server"
+  "id": "a4cf452c1e0375c3d4412cb550ad1783358468a3b3b777da4829d72c7d6fb74f",
+  "index": "risk-score.risk-score-latest-default",
+  "source": {
+    "@timestamp": "2021-03-10T14:51:05.766Z",
+    "host": {
+      "name": "siem-kibana",
+      "risk": {
+        "calculated_level": "Critical",
+        "calculated_score_norm": 90,
+        "id_field": "host.name",
+        "id_value": "siem-kibana",
+        "calculated_score": 150,
+        "category_1_score": 150,
+        "category_1_count": 1,
+        "notes": [],
+        "inputs": [
+          {
+            "id": "62895f54816047b9bf82929a61a6c571f41de9c2361670f6ef0136360e006f58",
+            "index": ".internal.alerts-security.alerts-default-000001",
+            "description": "New Rule Test",
+            "category": "category_1",
+            "risk_score": 70,
+            "timestamp": "2023-08-14T09:08:18.664Z"
+          },
+          {
+            "id": "e5bf3da3c855486ac7b40fa1aa33e19cf1380e413b79ed76bddf728f8fec4462",
+            "index": ".internal.alerts-security.alerts-default-000001",
+            "description": "New Rule Test",
+            "category": "category_1",
+            "risk_score": 70,
+            "timestamp": "2023-08-14T09:08:18.664Z"
+          }
+        ]
+      }
     }
-  },
-  "user": {
-    "name": "Arturo_Haley"
-  },
-  "event.kind": "signal",
-  "kibana.alert.original_time": "2023-04-11T20:17:14.851Z",
-  "kibana.alert.ancestors": [
-    {
-      "id": "8TD3cYcB1hicTK_CdP--",
-      "type": "event",
-      "index": "my-index",
-      "depth": 0
-    }
-  ],
-  "kibana.alert.status": "active",
-  "kibana.alert.workflow_status": "open",
-  "kibana.alert.depth": 1,
-  "kibana.alert.reason": "event on Host 4 created low alert 1.",
-  "kibana.alert.severity": "low",
-  "kibana.alert.risk_score": 21,
-  "kibana.alert.rule.actions": [],
-  "kibana.alert.rule.author": [],
-  "kibana.alert.rule.created_at": "2023-04-11T20:15:52.473Z",
-  "kibana.alert.rule.created_by": "elastic",
-  "kibana.alert.rule.description": "2",
-  "kibana.alert.rule.enabled": true,
-  "kibana.alert.rule.exceptions_list": [],
-  "kibana.alert.rule.false_positives": [],
-  "kibana.alert.rule.from": "now-360s",
-  "kibana.alert.rule.immutable": false,
-  "kibana.alert.rule.interval": "5m",
-  "kibana.alert.rule.indices": ["my*"],
-  "kibana.alert.rule.license": "",
-  "kibana.alert.rule.max_signals": 100,
-  "kibana.alert.rule.references": [],
-  "kibana.alert.rule.risk_score_mapping": [],
-  "kibana.alert.rule.rule_id": "cc066b08-b4d2-4e74-81cb-3cda5aaa612d",
-  "kibana.alert.rule.severity_mapping": [],
-  "kibana.alert.rule.threat": [],
-  "kibana.alert.rule.to": "now",
-  "kibana.alert.rule.type": "query",
-  "kibana.alert.rule.updated_at": "2023-04-11T20:18:11.024Z",
-  "kibana.alert.rule.updated_by": "elastic",
-  "kibana.alert.rule.version": 3,
-  "kibana.alert.rule.meta.from": "1m",
-  "kibana.alert.rule.meta.kibana_siem_app_url": "http://localhost:5601/app/security",
-  "kibana.alert.rule.risk_score": 21,
-  "kibana.alert.rule.severity": "low",
-  "kibana.alert.uuid": "856934e4-6d10-487e-9997-a9757b3f4927"
+  }
 }
 ```
 

From 9cd969dd6fa4d242d8a16cd33f248e309d2919eb Mon Sep 17 00:00:00 2001
From: Ryland Herrick <ryalnd@gmail.com>
Date: Fri, 8 Dec 2023 15:30:21 -0600
Subject: [PATCH 04/10] Add a more realistic category_1_count value

This represents the total number of alerts that were processed to create
this risk score; having a larger number is both more realistic, and also
highlights the fact that the number of inputs will be very small
compared to this number.
---
 rfcs/text/0042-risk-score-extensions.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/rfcs/text/0042-risk-score-extensions.md b/rfcs/text/0042-risk-score-extensions.md
index c13123fc1..412e378df 100644
--- a/rfcs/text/0042-risk-score-extensions.md
+++ b/rfcs/text/0042-risk-score-extensions.md
@@ -95,7 +95,7 @@ The following is an example risk score generated from Detection Engine Alerts, c
         "id_value": "siem-kibana",
         "calculated_score": 150,
         "category_1_score": 150,
-        "category_1_count": 1,
+        "category_1_count": 4354,
         "notes": [],
         "inputs": [
           {

From 323ed90799bef7e450ec05c8c832e1977325b823 Mon Sep 17 00:00:00 2001
From: Ryland Herrick <ryalnd@gmail.com>
Date: Fri, 8 Dec 2023 15:46:22 -0600
Subject: [PATCH 05/10] Add asset criticality fields

We've added this functionality within the product, we should discuss and
add these fields to ECS as well.
---
 rfcs/text/0042-risk-score-extensions.md | 11 +++++++++--
 rfcs/text/0042/risk.yml                 | 12 ++++++++++++
 2 files changed, 21 insertions(+), 2 deletions(-)

diff --git a/rfcs/text/0042-risk-score-extensions.md b/rfcs/text/0042-risk-score-extensions.md
index 412e378df..8d9f140e5 100644
--- a/rfcs/text/0042-risk-score-extensions.md
+++ b/rfcs/text/0042-risk-score-extensions.md
@@ -36,7 +36,6 @@ These fields are intended to allow future extensibility of our concept of an "id
 * `id_field`
 * `id_value`
 
-
 ### Risk Category Fields
 Some of the context here was discussed in Stage 0; please read the above for that. More specifically, these fields seek to provide the category contributions to the score, and the number of risk inputs in that category, across each of the five proposed categories:
 
@@ -51,8 +50,14 @@ Some of the context here was discussed in Stage 0; please read the above for tha
 * `category_5_score`
 * `category_5_count`
 
+### Asset Criticality Fields
+Thes fields represent the designated criticality of the entity being described in the document.
+
+* `criticality_level`
+* `criticality_modifier`
+
 ### Risk Explainability
-Beyond the per-category explanations, these fields' purpose is to provide more insight/data for the analyst to further investigate the components of the risk score.
+Beyond the category and criticality explanations above, these fields' purpose is to provide more insight/data for the analyst to further investigate the components of the risk score.
 
 * `risk.inputs`
   * Generally, these objects are meant as a convenience for one investigating risk; they are the "most risky" inputs as determined by the risk engine, and serve as a shortcut to further investigation.
@@ -96,6 +101,8 @@ The following is an example risk score generated from Detection Engine Alerts, c
         "calculated_score": 150,
         "category_1_score": 150,
         "category_1_count": 4354,
+        "criticality_level": "very_important",
+        "criticality_modifier": 2.0,
         "notes": [],
         "inputs": [
           {
diff --git a/rfcs/text/0042/risk.yml b/rfcs/text/0042/risk.yml
index 4ee75b866..1beb23cb4 100644
--- a/rfcs/text/0042/risk.yml
+++ b/rfcs/text/0042/risk.yml
@@ -108,6 +108,18 @@
         The number of risk input documents that contributed to the Category 5 score.
 
         Risk Categories logically group risk inputs from various domain use cases. Category 5 contains inputs from Anomalies.
+    - name: criticality_level
+      level: extended
+      type: keyword
+      example: very_important
+      description: >
+        The designated criticality level of the entity. Possible values are `not_important`, `important`, `very_important`, and `critical`.
+    - name: criticality_modifier
+      level: extended
+      type: float
+      example: 2.0
+      description: >
+        The numeric modifier corresponding to the criticality level of the entity, which is used as an input to the risk score calculation.
     - name: inputs
       level: extended
       type: object

From 54c42b54b7174496a9926bfb72e63de338f37cf0 Mon Sep 17 00:00:00 2001
From: Ryland Herrick <ryalnd@gmail.com>
Date: Fri, 8 Dec 2023 15:58:26 -0600
Subject: [PATCH 06/10] More clearly state that the category score is
 normalized

This was previously not clear from the examples/descriptions: category
scores will be normalized to the 0-100 range, and only the
`calculated_score` represents the "raw" score of the entity.
---
 rfcs/text/0042/risk.yml | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/rfcs/text/0042/risk.yml b/rfcs/text/0042/risk.yml
index 1beb23cb4..9da251648 100644
--- a/rfcs/text/0042/risk.yml
+++ b/rfcs/text/0042/risk.yml
@@ -33,7 +33,7 @@
       type: float
       example: 33.0
       description: >
-        The contribution of Category 1 to the overall risk score (`calculated_score`).
+        The contribution of Category 1 to the overall normalized risk score (`calculated_score_norm`).
 
         Risk Categories logically group risk inputs from various domain use cases. Category 1 includes Alerts, namely from Kibana's Detection Engine.
     - name: category_1_count
@@ -49,7 +49,7 @@
       type: float
       example: 35.0
       description: >
-        The contribution of Category 2 to the overall risk score (`calculated_score`).
+        The contribution of Category 2 to the overall normalized risk score (`calculated_score_norm`).
 
         Risk Categories logically group risk inputs from various domain use cases. Category 2 includes inputs from Posture Management.
     - name: category_2_count
@@ -65,7 +65,7 @@
       type: float
       example: 25.0
       description: >
-        The contribution of Category 3 to the overall risk score (`calculated_score`).
+        The contribution of Category 3 to the overall normalized risk score (`calculated_score_norm`).
 
         Risk Categories logically group risk inputs from various domain use cases. Category 3 includes inputs from Vulnerabilities.
     - name: category_3_count
@@ -81,7 +81,7 @@
       type: float
       example: 55.0
       description: >
-        The contribution of Category 4 to the overall risk score (`calculated_score`).
+        The contribution of Category 4 to the overall normalized risk score (`calculated_score_norm`).
 
         Risk Categories logically group risk inputs from various domain use cases. Category 4 includes Entity Contexts.
     - name: category_4_count
@@ -97,7 +97,7 @@
       type: float
       example: 75.0
       description: >
-        The contribution of Category 5 to the overall risk score (`calculated_score`).
+        The contribution of Category 5 to the overall normalized risk score (`calculated_score_norm`).
 
         Risk Categories logically group risk inputs from various domain use cases. Category 5 contains inputs from Anomalies.
     - name: category_5_count

From 3a21061ed9df2cac46c664d7c20a0ecfa74beabf Mon Sep 17 00:00:00 2001
From: Ryland Herrick <ryalnd@gmail.com>
Date: Fri, 8 Dec 2023 15:59:42 -0600
Subject: [PATCH 07/10] Add more realistic fields/values for our score document

* category scores are within 0-100
* category scores sum to the calculated_score_norm
* category 5 is present since criticality is present
---
 rfcs/text/0042-risk-score-extensions.md | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/rfcs/text/0042-risk-score-extensions.md b/rfcs/text/0042-risk-score-extensions.md
index 8d9f140e5..209c7e692 100644
--- a/rfcs/text/0042-risk-score-extensions.md
+++ b/rfcs/text/0042-risk-score-extensions.md
@@ -99,8 +99,10 @@ The following is an example risk score generated from Detection Engine Alerts, c
         "id_field": "host.name",
         "id_value": "siem-kibana",
         "calculated_score": 150,
-        "category_1_score": 150,
+        "category_1_score": 80,
         "category_1_count": 4354,
+        "category_5_score": 10,
+        "category_5_count": 1,
         "criticality_level": "very_important",
         "criticality_modifier": 2.0,
         "notes": [],

From a00f454ce1893ad3cdc5570713c7a14b472be960 Mon Sep 17 00:00:00 2001
From: Ryland Herrick <ryalnd@gmail.com>
Date: Fri, 8 Dec 2023 17:02:53 -0600
Subject: [PATCH 08/10] Fix allowed values for criticality_level

---
 rfcs/text/0042/risk.yml | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/rfcs/text/0042/risk.yml b/rfcs/text/0042/risk.yml
index 9da251648..107feda2b 100644
--- a/rfcs/text/0042/risk.yml
+++ b/rfcs/text/0042/risk.yml
@@ -113,7 +113,7 @@
       type: keyword
       example: very_important
       description: >
-        The designated criticality level of the entity. Possible values are `not_important`, `important`, `very_important`, and `critical`.
+        The designated criticality level of the entity. Possible values are `not_important`, `normal`, `important`, and `very_important`.
     - name: criticality_modifier
       level: extended
       type: float

From 7af698bbfacf240c038b1765812a57d8a205e24f Mon Sep 17 00:00:00 2001
From: Ryland Herrick <ryalnd@gmail.com>
Date: Tue, 19 Dec 2023 16:41:09 -0600
Subject: [PATCH 09/10] Swap Risk Categories 2 and 4

We decided to number our risk categories based on the order in which
they are introduced in kibana. Since Asset Criticality is being released
next, and AC corresponds to the Entity Contexts category, it's now
Category 2.
---
 rfcs/text/0042-risk-score-extensions.md |  4 ++--
 rfcs/text/0042/risk.yml                 | 16 ++++++++--------
 2 files changed, 10 insertions(+), 10 deletions(-)

diff --git a/rfcs/text/0042-risk-score-extensions.md b/rfcs/text/0042-risk-score-extensions.md
index 209c7e692..3fdcee533 100644
--- a/rfcs/text/0042-risk-score-extensions.md
+++ b/rfcs/text/0042-risk-score-extensions.md
@@ -101,8 +101,8 @@ The following is an example risk score generated from Detection Engine Alerts, c
         "calculated_score": 150,
         "category_1_score": 80,
         "category_1_count": 4354,
-        "category_5_score": 10,
-        "category_5_count": 1,
+        "category_2_score": 10,
+        "category_2_count": 1,
         "criticality_level": "very_important",
         "criticality_modifier": 2.0,
         "notes": [],
diff --git a/rfcs/text/0042/risk.yml b/rfcs/text/0042/risk.yml
index 107feda2b..3ea3319fd 100644
--- a/rfcs/text/0042/risk.yml
+++ b/rfcs/text/0042/risk.yml
@@ -47,19 +47,19 @@
     - name: category_2_score
       level: extended
       type: float
-      example: 35.0
+      example: 55.0
       description: >
         The contribution of Category 2 to the overall normalized risk score (`calculated_score_norm`).
 
-        Risk Categories logically group risk inputs from various domain use cases. Category 2 includes inputs from Posture Management.
+        Risk Categories logically group risk inputs from various domain use cases. Category 2 includes Entity Contexts.
     - name: category_2_count
       level: extended
       type: long
-      example: 1921
+      example: 1308
       description: >
         The number of risk input documents that contributed to the Category 2 score.
 
-        Risk Categories logically group risk inputs from various domain use cases. Category 2 includes inputs from Posture Management.
+        Risk Categories logically group risk inputs from various domain use cases. Category 2 includes Entity Contexts.
     - name: category_3_score
       level: extended
       type: float
@@ -79,19 +79,19 @@
     - name: category_4_score
       level: extended
       type: float
-      example: 55.0
+      example: 35.0
       description: >
         The contribution of Category 4 to the overall normalized risk score (`calculated_score_norm`).
 
-        Risk Categories logically group risk inputs from various domain use cases. Category 4 includes Entity Contexts.
+        Risk Categories logically group risk inputs from various domain use cases. Category 4 includes inputs from Posture Management.
     - name: category_4_count
       level: extended
       type: long
-      example: 1308
+      example: 1921
       description: >
         The number of risk input documents that contributed to the Category 4 score.
 
-        Risk Categories logically group risk inputs from various domain use cases. Category 4 includes Entity Contexts.
+        Risk Categories logically group risk inputs from various domain use cases. Category 4 includes inputs from Posture Management.
     - name: category_5_score
       level: extended
       type: float

From cd6e17c61fa6475e3a1338a5263c6a7c6e1d935d Mon Sep 17 00:00:00 2001
From: Ryland Herrick <ryalnd@gmail.com>
Date: Fri, 5 Jan 2024 15:39:14 -0600
Subject: [PATCH 10/10] Revert "Add asset criticality fields"

This reverts commit 323ed90799bef7e450ec05c8c832e1977325b823.

 Conflicts:
	rfcs/text/0042-risk-score-extensions.md
	rfcs/text/0042/risk.yml
---
 rfcs/text/0042-risk-score-extensions.md | 11 ++---------
 rfcs/text/0042/risk.yml                 | 12 ------------
 2 files changed, 2 insertions(+), 21 deletions(-)

diff --git a/rfcs/text/0042-risk-score-extensions.md b/rfcs/text/0042-risk-score-extensions.md
index 3fdcee533..5dc90a062 100644
--- a/rfcs/text/0042-risk-score-extensions.md
+++ b/rfcs/text/0042-risk-score-extensions.md
@@ -36,6 +36,7 @@ These fields are intended to allow future extensibility of our concept of an "id
 * `id_field`
 * `id_value`
 
+
 ### Risk Category Fields
 Some of the context here was discussed in Stage 0; please read the above for that. More specifically, these fields seek to provide the category contributions to the score, and the number of risk inputs in that category, across each of the five proposed categories:
 
@@ -50,14 +51,8 @@ Some of the context here was discussed in Stage 0; please read the above for tha
 * `category_5_score`
 * `category_5_count`
 
-### Asset Criticality Fields
-Thes fields represent the designated criticality of the entity being described in the document.
-
-* `criticality_level`
-* `criticality_modifier`
-
 ### Risk Explainability
-Beyond the category and criticality explanations above, these fields' purpose is to provide more insight/data for the analyst to further investigate the components of the risk score.
+Beyond the per-category explanations, these fields' purpose is to provide more insight/data for the analyst to further investigate the components of the risk score.
 
 * `risk.inputs`
   * Generally, these objects are meant as a convenience for one investigating risk; they are the "most risky" inputs as determined by the risk engine, and serve as a shortcut to further investigation.
@@ -103,8 +98,6 @@ The following is an example risk score generated from Detection Engine Alerts, c
         "category_1_count": 4354,
         "category_2_score": 10,
         "category_2_count": 1,
-        "criticality_level": "very_important",
-        "criticality_modifier": 2.0,
         "notes": [],
         "inputs": [
           {
diff --git a/rfcs/text/0042/risk.yml b/rfcs/text/0042/risk.yml
index 3ea3319fd..661f2caa1 100644
--- a/rfcs/text/0042/risk.yml
+++ b/rfcs/text/0042/risk.yml
@@ -108,18 +108,6 @@
         The number of risk input documents that contributed to the Category 5 score.
 
         Risk Categories logically group risk inputs from various domain use cases. Category 5 contains inputs from Anomalies.
-    - name: criticality_level
-      level: extended
-      type: keyword
-      example: very_important
-      description: >
-        The designated criticality level of the entity. Possible values are `not_important`, `normal`, `important`, and `very_important`.
-    - name: criticality_modifier
-      level: extended
-      type: float
-      example: 2.0
-      description: >
-        The numeric modifier corresponding to the criticality level of the entity, which is used as an input to the risk score calculation.
     - name: inputs
       level: extended
       type: object