-
Notifications
You must be signed in to change notification settings - Fork 418
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.
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] Stage 0: Introducing new field in rule namespace #2330
Conversation
Updating the temaplate for RFC Stage 0 for adding 2 new rule fields: rule.tags and rule.remediation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Left some initial comments.
rfcs/0000-rfc-template.md
Outdated
@@ -97,6 +108,7 @@ e.g.: | |||
## References | |||
|
|||
<!-- Insert any links appropriate to this RFC in this section. --> | |||
EPIC with detailed discussion on addition of these fields - https://github.com/elastic/security-team/issues/7658 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I recommend removing any references to Elastic-only discussions or references. For anyone outside Elastic, these links will just return a 404 error.
If you want to link the two discussions, add a link on the private to the public.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ACK
rfcs/0000-rfc-template.md
Outdated
Field | Type | Description /Usage | ||
-- | -- | -- | -- | -- | ||
rule.tags | array | Used to track the set of tags applied to a rule | Customers can use it to indicate: author, benchmark partial name, rule number, rule category etc. It will be useful when we extend the capability to add more rules | ||
rule.remediation | array | Used to capture remediation instructions that come from the benchmark / framework the rule is from |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How would this value be used as an array
? From the description, I'd expect a block of text with the instructions?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There is possibility to have multiple remediation options for same misconfiguration, hence an array makes more sense. For example, we provide remediation manual steps, cli commands for CSPM misconfigurations.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@kfirpeled @maxcold thoughts on this? As @smriti0321 mentioned, from a product perspective, if there are multiple remediation options, we'd love to capture them all and present them in our flyout. From a technical perspective we can group all of these into one field we render as markdown, or as an array of values, etc. Can you help decide what the best path is here from a data type perspective? Thx!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Right now it's just a markdown text for our native integration, for Wiz it's also just a string. Unless we want to have a more complex structure for each remediation instruction, text
should be enough as a type in my opinion.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There is possibility to have multiple remediation options for same misconfiguration, hence an array makes more sense. For example, we provide remediation manual steps, cli commands for CSPM misconfigurations.
I'm not sure I followed, currently, we don't have any examples of multiple remediation instructions. Can you please provide one?
and another FYI, it introduces a breaking change. so we need to think it through from a technical perspective as well
rfcs/0000-rfc-template.md
Outdated
|
||
Field | Type | Description /Usage | ||
-- | -- | -- | -- | -- | ||
rule.tags | array | Used to track the set of tags applied to a rule | Customers can use it to indicate: author, benchmark partial name, rule number, rule category etc. It will be useful when we extend the capability to add more rules |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ECS already provides a top-level tags
field: https://www.elastic.co/guide/en/ecs/current/ecs-base.html#field-tags.
Could the existing tags
field be used for the same purpose without creating another tags
field?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This could be the right approach to reuse top-level tags to include rules tag.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No comment from my side.
Incorporating review comments.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@smriti0321 it looks like you directly updated the RFC template file (rfcs/0000-rfc-template.md
). Pls revert this change and create a new file in the rfcs/text
folder.
rfcs/0000-rfc-template.md
Outdated
|
||
Field | Type | Description /Usage | ||
-- | -- | -- | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The table isn't rendering. Removing this line break (31) will fix it.
rfcs/0000-rfc-template.md
Outdated
Field | Type | Description /Usage | ||
-- | -- | -- | -- | -- | ||
rule.tags | array | Used to track the set of tags applied to a rule | Customers can use it to indicate: author, benchmark partial name, rule number, rule category etc. It will be useful when we extend the capability to add more rules | ||
rule.remediation | array | Used to capture remediation instructions that come from the benchmark / framework the rule is from |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@kfirpeled @maxcold thoughts on this? As @smriti0321 mentioned, from a product perspective, if there are multiple remediation options, we'd love to capture them all and present them in our flyout. From a technical perspective we can group all of these into one field we render as markdown, or as an array of values, etc. Can you help decide what the best path is here from a data type perspective? Thx!
@smriti0321 whats the plan for capturing benchmark/framework metadata? The existing
For context, here is an example of a wiz findings that contains multiple mapped benchmarks/frameworks: Just the benchmarks / frameworks"securitySubCategories": [
{
"category": {
"framework": { "id": "wf-id-115", "name": "UK Cyber Essentials" },
"id": "wct-id-2360",
"name": "1 Firewalls"
},
"id": "wsct-id-15168",
"title": "1.1 Change default administrative passwords"
},
{
"category": {
"framework": { "id": "wf-id-13", "name": "NIST CSF v1.1" },
"id": "wct-id-363",
"name": "2 Business Environment (ID.BE)"
},
"id": "wsct-id-37",
"title": "5 Resilience requirements to support delivery of critical services are established"
},
{
"category": {
"framework": { "id": "wf-id-13", "name": "NIST CSF v1.1" },
"id": "wct-id-370",
"name": "10 Information Protection Processes and Procedures (PR.IP)"
},
"id": "wsct-id-76",
"title": "9 Response plans (Incident Response and Business Continuity) and recovery plans (Incident Recovery and Disaster Recovery) are in place and managed"
},
{
"category": {
"framework": { "id": "wf-id-13", "name": "NIST CSF v1.1" },
"id": "wct-id-372",
"name": "12 Protective Technology (PR.PT)"
},
"id": "wsct-id-689",
"title": "5 Mechanisms (e.g., failsafe, load balancing, hot swap) are implemented to achieve resilience requirements in normal and adverse situations"
},
{
"category": {
"framework": { "id": "wf-id-14", "name": "CSA CCM v4.0.5" },
"id": "wct-id-1062",
"name": "5 - CEK Cryptography, Encryption \u0026 Key Management"
},
"id": "wsct-id-6165",
"title": "CEK-01 Encryption and Key Management Policy and Procedures - Establish, document, approve, communicate, apply, evaluate and maintain\npolicies and procedures for Cryptography, Encryption and Key Management. Review\nand update the policies and procedures at least annually."
},
{
"category": {
"framework": { "id": "wf-id-14", "name": "CSA CCM v4.0.5" },
"id": "wct-id-1074",
"name": "17 - UEM Universal Endpoint Management"
},
"id": "wsct-id-6322",
"title": "UEM-08 Storage Encryption - Protect information from unauthorized disclosure on managed endpoint\ndevices with storage encryption."
},
{
"category": {
"framework": { "id": "wf-id-48", "name": "NIST SP 800-53 Revision 4" },
"id": "wct-id-1181",
"name": "CM CONFIGURATION MANAGEMENT"
},
"id": "wsct-id-6836",
"title": "CM-7 LEAST FUNCTIONALITY"
},
{
"category": {
"framework": { "id": "wf-id-1", "name": "Wiz for Risk Assessment" },
"id": "wct-id-940",
"name": "Operationalization"
},
"id": "wsct-id-10421",
"title": "Informational configuration"
},
{
"category": {
"framework": { "id": "wf-id-13", "name": "NIST CSF v1.1" },
"id": "wct-id-370",
"name": "10 Information Protection Processes and Procedures (PR.IP)"
},
"id": "wsct-id-71",
"title": "4 Backups of information are conducted, maintained, and tested periodically"
},
{
"category": {
"framework": { "id": "wf-id-3", "name": "ISO/IEC 27001" },
"id": "wct-id-589",
"name": "A.12 Operations security"
},
"id": "wsct-id-635",
"title": "A.12.3.1 Information backup"
},
{
"category": {
"framework": { "id": "wf-id-14", "name": "CSA CCM v4.0.5" },
"id": "wct-id-1061",
"name": "4 - CCC Change Control and Configuration Management"
},
"id": "wsct-id-6164",
"title": "CCC-09 Change Restoration - Define and implement a process to proactively roll back changes to\na previous known good state in case of errors or security concerns."
},
{
"category": {
"framework": { "id": "wf-id-105", "name": "Wiz (Legacy)" },
"id": "wct-id-2136",
"name": "Operationalization"
},
"id": "wsct-id-5540",
"title": "Operationalization"
}
] Full finding{
"analyzedAt": "2024-05-29T01:03:24.600785Z",
"firstSeenAt": "2024-05-29T01:03:26.815114Z",
"id": "bb379d62-72bf-57c8-8e68-a043696a072b",
"ignoreRules": null,
"remediation": "To monitor an instance stop scheduled event for the EC2 instance, follow [this link](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/monitoring-instances-status-check_sched.html).\n",
"resource": {
"id": "72b98370-615e-5136-a614-71269ddef677",
"name": "Demo vulns findings",
"nativeType": "virtualMachine",
"projects": [
{
"id": "83b76efe-a7b6-5762-8a53-8e8f59e68bd8",
"name": "Project 2",
"riskProfile": { "businessImpact": "MBI" }
},
{
"id": "af52828c-4eb1-5c4e-847c-ebc3a5ead531",
"name": "project 4",
"riskProfile": { "businessImpact": "MBI" }
},
{
"id": "d6ac50bb-aec0-52fc-80ab-bacd7b02f178",
"name": "Project1",
"riskProfile": { "businessImpact": "MBI" }
}
],
"providerId": "arn:aws:ec2:us-east-2:998231069301:instance/i-07602bddd9c7a3052",
"region": "us-east-2",
"subscription": {
"cloudProvider": "AWS",
"externalId": "998231069301",
"id": "94e76baa-85fd-5928-b829-1669a2ca9660",
"name": "wiz-integrations"
},
"tags": [{ "key": "Name", "value": "Demo vulns findings" }],
"type": "VIRTUAL_MACHINE"
},
"result": "FAIL",
"rule": {
"description": "This rule checks whether there is an instance stop scheduled event for the EC2 instance. \nThis rule fails if there is at least one `Events` element whose `Code` field is set to `instance-stop`. \nThe event applies to instances backed by Amazon EBS. This event indicates that at the scheduled time, the instance is stopped, and when it is started again, it is migrated to a new host. Be aware of instance-stop scheduled events to avoid unexpected data loss and downtime.\n\u003e**Note** \n\u003eThis rule does not indicate any misconfiguration and is informational only.",
"functionAsControl": false,
"graphId": "0dd0ca67-e17e-5e0d-b296-08ce779953f6",
"id": "5076dc62-3fbd-4ee9-9495-3ca295aeac99",
"name": "EC2 instance with an upcoming instance stop scheduled event",
"remediationInstructions": "To monitor an instance stop scheduled event for the EC2 instance, follow [this link](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/monitoring-instances-status-check_sched.html).\n"
},
"securitySubCategories": [
{
"category": {
"framework": { "id": "wf-id-115", "name": "UK Cyber Essentials" },
"id": "wct-id-2360",
"name": "1 Firewalls"
},
"id": "wsct-id-15168",
"title": "1.1 Change default administrative passwords"
},
{
"category": {
"framework": { "id": "wf-id-13", "name": "NIST CSF v1.1" },
"id": "wct-id-363",
"name": "2 Business Environment (ID.BE)"
},
"id": "wsct-id-37",
"title": "5 Resilience requirements to support delivery of critical services are established"
},
{
"category": {
"framework": { "id": "wf-id-13", "name": "NIST CSF v1.1" },
"id": "wct-id-370",
"name": "10 Information Protection Processes and Procedures (PR.IP)"
},
"id": "wsct-id-76",
"title": "9 Response plans (Incident Response and Business Continuity) and recovery plans (Incident Recovery and Disaster Recovery) are in place and managed"
},
{
"category": {
"framework": { "id": "wf-id-13", "name": "NIST CSF v1.1" },
"id": "wct-id-372",
"name": "12 Protective Technology (PR.PT)"
},
"id": "wsct-id-689",
"title": "5 Mechanisms (e.g., failsafe, load balancing, hot swap) are implemented to achieve resilience requirements in normal and adverse situations"
},
{
"category": {
"framework": { "id": "wf-id-14", "name": "CSA CCM v4.0.5" },
"id": "wct-id-1062",
"name": "5 - CEK Cryptography, Encryption \u0026 Key Management"
},
"id": "wsct-id-6165",
"title": "CEK-01 Encryption and Key Management Policy and Procedures - Establish, document, approve, communicate, apply, evaluate and maintain\npolicies and procedures for Cryptography, Encryption and Key Management. Review\nand update the policies and procedures at least annually."
},
{
"category": {
"framework": { "id": "wf-id-14", "name": "CSA CCM v4.0.5" },
"id": "wct-id-1074",
"name": "17 - UEM Universal Endpoint Management"
},
"id": "wsct-id-6322",
"title": "UEM-08 Storage Encryption - Protect information from unauthorized disclosure on managed endpoint\ndevices with storage encryption."
},
{
"category": {
"framework": { "id": "wf-id-48", "name": "NIST SP 800-53 Revision 4" },
"id": "wct-id-1181",
"name": "CM CONFIGURATION MANAGEMENT"
},
"id": "wsct-id-6836",
"title": "CM-7 LEAST FUNCTIONALITY"
},
{
"category": {
"framework": { "id": "wf-id-1", "name": "Wiz for Risk Assessment" },
"id": "wct-id-940",
"name": "Operationalization"
},
"id": "wsct-id-10421",
"title": "Informational configuration"
},
{
"category": {
"framework": { "id": "wf-id-13", "name": "NIST CSF v1.1" },
"id": "wct-id-370",
"name": "10 Information Protection Processes and Procedures (PR.IP)"
},
"id": "wsct-id-71",
"title": "4 Backups of information are conducted, maintained, and tested periodically"
},
{
"category": {
"framework": { "id": "wf-id-3", "name": "ISO/IEC 27001" },
"id": "wct-id-589",
"name": "A.12 Operations security"
},
"id": "wsct-id-635",
"title": "A.12.3.1 Information backup"
},
{
"category": {
"framework": { "id": "wf-id-14", "name": "CSA CCM v4.0.5" },
"id": "wct-id-1061",
"name": "4 - CCC Change Control and Configuration Management"
},
"id": "wsct-id-6164",
"title": "CCC-09 Change Restoration - Define and implement a process to proactively roll back changes to\na previous known good state in case of errors or security concerns."
},
{
"category": {
"framework": { "id": "wf-id-105", "name": "Wiz (Legacy)" },
"id": "wct-id-2136",
"name": "Operationalization"
},
"id": "wsct-id-5540",
"title": "Operationalization"
}
],
"severity": "NONE",
"status": "OPEN",
"targetExternalId": "i-07602bddd9c7a3052",
"targetObjectProviderUniqueId": "arn:aws:ec2:us-east-2:998231069301:instance/i-07602bddd9c7a3052"
}
|
@tinnytintin10 we plan to capture ruleset through a separate RFC as per my discussion with @trisch-me |
@ebeahan and @tinnytintin10 could you please review the changes. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lgtm for the stage 0
@tinnytintin10 Requested changes are taken care of, could you please approve this? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
* Add .caseless subfield to process.name & process.executable (elastic#2341) Adds a subfield to the process.name and process.executable fields to improve the compatibility of data sources like System, Sysmon, etc., with our Elastic Defend data, which enables us to handle language limitations in KQL more effectively. * Revert "Add .caseless subfield to process.name & process.executable" (elastic#2350) This reverts commit 7815b3f from elastic#2341. This is being reverted due to storage concerns. The goal will be to advance the native querying capabilities (ES|QL, KQL) of the Elastic stack such that this extra normalized multi-field is not necessary. In the meantime, localized overrides of the ECS field definition will be used to add the additional multi-field where needed. The downside of localized overrides are that it creates inconsistency across usages of the this field. * [RFC] Apple Platform specific fields (elastic#2338) Adds RFS stage 0 --------- Co-authored-by: Alexandra Konrad <alexandra.konrad@elastic.co> Co-authored-by: Michael Wolf <michael.wolf@elastic.co> * Add renovate.json (elastic#2352) Co-authored-by: elastic-renovate-prod[bot] <174716857+elastic-renovate-prod[bot]@users.noreply.github.com> Co-authored-by: Michael Wolf <michael.wolf@elastic.co> * Update template fields (elastic#2354) Update some templated fields that were missed before merging the RFC * Pin dependencies (elastic#2355) Co-authored-by: elastic-renovate-prod[bot] <174716857+elastic-renovate-prod[bot]@users.noreply.github.com> Co-authored-by: Michael Wolf <michael.wolf@elastic.co> * Update dependency PyYAML to v6.0.2 (elastic#2356) Co-authored-by: elastic-renovate-prod[bot] <174716857+elastic-renovate-prod[bot]@users.noreply.github.com> Co-authored-by: Michael Wolf <michael.wolf@elastic.co> * Update dependency gitpython to v3.1.43 (elastic#2358) Co-authored-by: elastic-renovate-prod[bot] <174716857+elastic-renovate-prod[bot]@users.noreply.github.com> Co-authored-by: Michael Wolf <michael.wolf@elastic.co> * Update dependency yamllint to v1.35.1 (elastic#2361) Co-authored-by: elastic-renovate-prod[bot] <174716857+elastic-renovate-prod[bot]@users.noreply.github.com> Co-authored-by: Michael Wolf <michael.wolf@elastic.co> * Update stale PR message (elastic#2369) Add a friendlier stale PR message, based from the [Beats stale message](https://github.com/elastic/beats/blob/main/.github/stale.yml#L63-L74). This will hopefully also prompt contributors to respond, so we'll be better able to track PRs people are still interested in contributing. * Update actions/checkout action to v4 (elastic#2362) Co-authored-by: elastic-renovate-prod[bot] <174716857+elastic-renovate-prod[bot]@users.noreply.github.com> Co-authored-by: Michael Wolf <michael.wolf@elastic.co> * Update actions/github-script action to v7 (elastic#2363) Co-authored-by: elastic-renovate-prod[bot] <174716857+elastic-renovate-prod[bot]@users.noreply.github.com> Co-authored-by: Michael Wolf <michael.wolf@elastic.co> * Update actions/setup-python action to v5 (elastic#2364) Co-authored-by: elastic-renovate-prod[bot] <174716857+elastic-renovate-prod[bot]@users.noreply.github.com> Co-authored-by: Michael Wolf <michael.wolf@elastic.co> * Update actions/stale action to v9 (elastic#2365) Co-authored-by: elastic-renovate-prod[bot] <174716857+elastic-renovate-prod[bot]@users.noreply.github.com> Co-authored-by: Michael Wolf <michael.wolf@elastic.co> * Update dependency mock to v5 (elastic#2367) Co-authored-by: elastic-renovate-prod[bot] <174716857+elastic-renovate-prod[bot]@users.noreply.github.com> Co-authored-by: Michael Wolf <michael.wolf@elastic.co> * Update dependency ubuntu to v22 (elastic#2368) Co-authored-by: elastic-renovate-prod[bot] <174716857+elastic-renovate-prod[bot]@users.noreply.github.com> Co-authored-by: Michael Wolf <michael.wolf@elastic.co> * Update dependency autopep8 to v1.7.0 (elastic#2359) Update dependency autopep8 to v1.7.0 --------- Co-authored-by: elastic-renovate-prod[bot] <174716857+elastic-renovate-prod[bot]@users.noreply.github.com> Co-authored-by: Michael Wolf <michael.wolf@elastic.co> * Update dependency autopep8 to v2 (elastic#2366) * Update dependency autopep8 to v2 --------- Co-authored-by: elastic-renovate-prod[bot] <174716857+elastic-renovate-prod[bot]@users.noreply.github.com> Co-authored-by: Michael Wolf <michael.wolf@elastic.co> * add license header (elastic#2377) * Update actions/setup-python digest to f677139 (elastic#2374) Co-authored-by: elastic-renovate-prod[bot] <174716857+elastic-renovate-prod[bot]@users.noreply.github.com> Co-authored-by: Michael Wolf <michael.wolf@elastic.co> * [RFC] Stage 0: Introducing new field in rule namespace (elastic#2330) * Update 0000-rfc-template.md Updating the temaplate for RFC Stage 0 for adding 2 new rule fields: rule.tags and rule.remediation * Update 0000-rfc-template.md Incorporating review comments. * Renaming the template file with recommended name * Resolving conflicts * Removing Tag Field * Resolving comments from @trisch-me * Moving file to rfcs/text folder as per @trisch-me comment. using next number in series. * I saw number 44 was used in a recent RFC, using next number in series --------- Co-authored-by: Eric Beahan <eric.beahan@elastic.co> Co-authored-by: Alexandra Konrad <alexandra.konrad@elastic.co> * [RFC] Stage 2: Adding Apple Platform specific fields (elastic#2370) Updating the RFC and moving it to stage two. * code blocks specified language yaml (elastic#2380) Co-authored-by: Michael Wolf <michael.wolf@elastic.co> * trim trailing whitespace in schema (elastic#2379) Co-authored-by: Michael Wolf <michael.wolf@elastic.co> * [RFC] Stage 0: Introducing new fields in ECS vulnerability field set (elastic#2331) * RFC to add new fields in ECS vulnerability field set RFC to add new fields in ECS vulnerability field set * Moving to separate file * set title and add stage 0 PR # * clean up fields table markdown * Moving to (rfcs/text) and renaming file to next number in series. * Resolving the comments from @trisch-me * Update rfcs/text/0045-additional-vulnerability-fields.md Co-authored-by: Alexandra Konrad <alexandra.konrad@elastic.co> * Update rfcs/text/0045-additional-vulnerability-fields.md Co-authored-by: Alexandra Konrad <alexandra.konrad@elastic.co> * Making changed to the date format as per comments from @trisch-me * Resolving @trisch-me comments * Resolving latest comments * Update rfcs/text/0045-additional-vulnerability-fields.md Co-authored-by: Alexandra Konrad <alexandra.konrad@elastic.co> --------- Co-authored-by: Eric Beahan <eric.beahan@elastic.co> Co-authored-by: Alexandra Konrad <alexandra.konrad@elastic.co> * Fix type in code signature (elastic#2382) Change the type of code_signature.flags to keyword, which is what it should be. Also add a unit test that will verify all types are valid. * Enforce yamllint in CI (elastic#2381) Start running and enforcing yamllint checks in CI. * Add Stage0 RFC for new fields for fileless execution on Linux (elastic#2322) * Add support for settings * Fix settings merging * Restrict test workflow * Fix merge conflicts * Less restrictive * Add docker files and pipeline * Make building more restrictive * Simplify build workflow * Update tagging strategy * Removing unused variable * Kick? * Anchors aren't supported 😭 * Fix role name * Test branch name * Remove extra default update (#3) * Remove extra default update * Fix role name * Add support for a top-level type (#4) * Add support for a top-level type * Actually, don't need to be all the complicated * Type needs to be nested within the field name (#5) * Add documention for parameters field (#6) * Add undocumented field argument * Remove the PR template --------- Co-authored-by: Jonhnathan <26856693+w0rk3r@users.noreply.github.com> Co-authored-by: Andrew Kroh <andrew.kroh@elastic.co> Co-authored-by: Thijs Xhaflaire <thijsxhaflaire31@hotmail.com> Co-authored-by: Alexandra Konrad <alexandra.konrad@elastic.co> Co-authored-by: Michael Wolf <michael.wolf@elastic.co> Co-authored-by: elastic-renovate-prod[bot] <174716857+elastic-renovate-prod[bot]@users.noreply.github.com> Co-authored-by: Stefan Bischof <bipolis@bipolis.org> Co-authored-by: Smriti <152067238+smriti0321@users.noreply.github.com> Co-authored-by: Eric Beahan <eric.beahan@elastic.co> Co-authored-by: Michal Stanek <75310947+stanek-michal@users.noreply.github.com>
Updating the template for ECS RFC Stage 0 for adding 1 new rule fields:
make test
?make
and committed those changes?