Add applies_to for security reference (#630)

Author: lcawl

reference/security/fields-and-object-schemas/alert-schema.md

@@ -1,4 +1,8 @@
 ---
+applies_to:
+  stack: all
+  serverless:
+    security: all
 mapped_pages:
   - https://www.elastic.co/guide/en/security/current/alert-schema.html
   - https://www.elastic.co/guide/en/serverless/current/security-alert-schema.html
@@ -135,5 +139,5 @@ The non-ECS fields listed below are beta and subject to change.
 | `kibana.alert.url` | The shareable URL for the alert.<br>NOTE: This field appears only if you’ve set the [`server.publicBaseUrl`](asciidocalypse://docs/reference/configuration-reference/general-settings.md#server-publicBaseUrl) configuration setting in the `kibana.yml` file.<br>Type: long |
 | `kibana.alert.workflow_tags` | List of tags added to an alert.<br><br>This field can contain an array of values, for example: `["False Positive", "production"]`<br><br>Type: keyword<br> |
 | `kibana.alert.workflow_assignee_ids` | List of users assigned to an alert.<br><br>An array of unique identifiers (UIDs) for user profiles, for example: `["u_1-0CcWliOCQ9T2MrK5YDjhpxZ_AcxPKt3pwaICcnAUY_0, u_2-0CcWliOCQ9T2MrK5YDjhpxZ_AcxPKt3pwaICcnAUY_1"]`<br><br>UIDs are linked to user profiles that are automatically created when users first log into a deployment. These profiles contain names, emails, profile avatars, and other user settings.<br><br>Type: string[]<br> |
-| `kibana.alert.intended_timestamp` | Shows the alert’s estimated timestamp, had the alert been created when the source event initially occurred. The value in this field is determined by the way the rule was run:<br><br>* **Scheduled run**: Alerts created by scheduled runs have the same timestamp as the `@timestamp` field, which shows when the alert was created.<br>* **Manual run**: Alerts created by manual runs have a timestamp that falls within the time range specified for the manual run. For example, if you set a rule to manually run on event data from `10/01/2024 05:00 PM` to `10/07/2024 05:00 PM`, the `kibana.alert.intended_timestamp` value will be a date and time within that range.<br><br>Type: date<br> |
+| `kibana.alert.intended_timestamp` | Shows the alert’s estimated timestamp, had the alert been created when the source event initially occurred. The value in this field is determined by the way the rule was run:<br><br>- **Scheduled run**: Alerts created by scheduled runs have the same timestamp as the `@timestamp` field, which shows when the alert was created.<br>- **Manual run**: Alerts created by manual runs have a timestamp that falls within the time range specified for the manual run. For example, if you set a rule to manually run on event data from `10/01/2024 05:00 PM` to `10/07/2024 05:00 PM`, the `kibana.alert.intended_timestamp` value will be a date and time within that range.<br><br>Type: date<br> |
 | `kibana.alert.rule.execution.type` | Shows if an alert was created by a manual run or a scheduled run. The value can be `manual` or `scheduled`.<br><br>Type: keyword<br> |

reference/security/fields-and-object-schemas/siem-field-reference.md

@@ -1,12 +1,16 @@
 ---
+applies_to:
+  stack: all
+  serverless:
+    security: all
 mapped_pages:
   - https://www.elastic.co/guide/en/security/current/siem-field-reference.html
   - https://www.elastic.co/guide/en/serverless/current/security-siem-field-reference.html
 ---
 
 # Elastic Security ECS field reference [siem-field-reference]
 
-This section lists [Elastic Common Schema](https://www.elastic.co/guide/en/ecs/current to provide an optimal SIEM and security analytics experience to users. These fields are used to display data, provide rule previews, enable detection by prebuilt detection rules, provide context during rule triage and investigation, escalate to cases, and more.
+This section lists [Elastic Common Schema](asciidocalypse://ecs/docs/reference/index.md) fields that provide an optimal SIEM and security analytics experience to users. These fields are used to display data, provide rule previews, enable detection by prebuilt detection rules, provide context during rule triage and investigation, escalate to cases, and more.
 
 ::::{important}
 We recommend you use {{agent}} integrations or {{beats}}  to ship your data to {{elastic-sec}}. {{agent}} integrations and Beat modules (for example, [{{filebeat}} modules](asciidocalypse://docs/beats/docs/reference/filebeat/filebeat-modules.md)) are ECS-compliant, which means data they ship to {{elastic-sec}} will automatically populate the relevant ECS fields. If you plan to use a custom implementation to map your data to ECS fields (see [how to map data to ECS](asciidocalypse://docs/reference/ecs-converting.md)), ensure the [always required fields](#siem-always-required-fields) are populated. Ideally, all relevant ECS fields should be populated as well.

reference/security/fields-and-object-schemas/timeline-object-schema.md

@@ -1,4 +1,8 @@
 ---
+applies_to:
+  stack: all
+  serverless:
+    security: all
 mapped_pages:
   - https://www.elastic.co/guide/en/security/current/timeline-object-schema.html
   - https://www.elastic.co/guide/en/serverless/current/security-timeline-object-schema.html