-
Notifications
You must be signed in to change notification settings - Fork 415
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] Stge 0 - New fieldset for volume device #2201
Merged
Merged
Changes from 18 commits
Commits
Show all changes
19 commits
Select commit
Hold shift + click to select a range
d8910b4
save draft
Trinity2019 32977a2
update
Trinity2019 30b22a2
update
Trinity2019 64e8b18
update
Trinity2019 c44276d
update
Trinity2019 a358cb7
update
Trinity2019 e91b13f
update
Trinity2019 800c2e8
update
Trinity2019 49b1b8a
update
Trinity2019 84755be
update
Trinity2019 e135219
add writable
Trinity2019 c47287e
review feedback
Trinity2019 b1d9d72
review feedback
Trinity2019 e206e50
review feedback
Trinity2019 6596549
review feedback
Trinity2019 fb435f5
update names
Trinity2019 fe9c40c
include hard disks
Trinity2019 fc2f4e1
Merge branch 'main' into removable_media_stage0
ebeahan 33d3715
setting RFC # and date
ebeahan File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,138 @@ | ||
# 0000: volume device | ||
<!-- Leave this ID at 0000. The ECS team will assign a unique, contiguous RFC number upon merging the initial stage of this RFC. --> | ||
|
||
- Stage: **0 (strawperson)** <!-- Update to reflect target stage. See https://elastic.github.io/ecs/stages.html --> | ||
- Date: **TBD** <!-- The ECS team sets this date at merge time. This is the date of the latest stage advancement. --> | ||
|
||
<!-- | ||
As you work on your RFC, use the "Stage N" comments to guide you in what you should focus on, for the stage you're targeting. | ||
Feel free to remove these comments as you go along. | ||
--> | ||
|
||
<!-- | ||
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. | ||
--> | ||
|
||
This RFC propose adding the volume device fieldset to describe volume storage devices such as hard disks, removable USB, mountable virtual disks such as ISO. | ||
|
||
* volume.mount_name | ||
* volume.device_name | ||
* volume.dos_name | ||
* volume.nt_name | ||
* volume.bus_type | ||
* volume.writable | ||
* volume.default_access | ||
* volume.file_system_type | ||
* volume.product_id | ||
* volume.product_name | ||
* volume.vendor_id | ||
* volume.vendor_name | ||
* volume.serial_number | ||
* volume.volume_device_type | ||
* volume.action | ||
* volume.size | ||
|
||
These volume device fields can be used to describe some events and alerts associated with a volume device, which was proven to be [useful](https://www.elastic.co/security-labs/Hunting-for-Suspicious-Windows-Libraries-for-Execution-and-Evasion) for Elastic Defend. | ||
|
||
These fields can also be used by the products and features to manage such devices based on their properties such as serial number and vendor name, etc. | ||
|
||
<!-- | ||
Stage 1: If the changes include field additions or modifications, please create a folder titled as the RFC number under rfcs/text/. This will be where proposed schema changes as standalone YAML files or extended example mappings and larger source documents will go as the RFC is iterated upon. | ||
--> | ||
|
||
<!-- | ||
Stage X: Provide a brief explanation of why the proposal is being marked as abandoned. This is useful context for anyone revisiting this proposal or considering similar changes later on. | ||
--> | ||
|
||
## 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. | ||
--> | ||
|
||
## Usage | ||
|
||
<!-- | ||
Stage 1: Describe at a high-level how these field changes will be used in practice. Real world examples are encouraged. The goal here is to understand how people would leverage these fields to gain insights or solve problems. ~1-3 paragraphs. | ||
--> | ||
|
||
## Source data | ||
|
||
The source of this data comes from monitoring a host, a Virtual Machine, or a k8s node. | ||
|
||
<!-- | ||
Stage 1: Provide a high-level description of example sources of data. This does not yet need to be a concrete example of a source document, but instead can simply describe a potential source (e.g. nginx access log). This will ultimately be fleshed out to include literal source examples in a future stage. The goal here is to identify practical sources for these fields in the real world. ~1-3 sentences or unordered list. | ||
--> | ||
|
||
<!-- | ||
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. | ||
--> | ||
|
||
<!-- | ||
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. | ||
--> | ||
|
||
## 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 | ||
|
||
<!-- | ||
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. | ||
|
||
* @Trinity2019 | author | ||
* @ricardoelastic | reviewer | ||
|
||
<!-- | ||
Who will be or has been consulted on the contents of this RFC? Identify authorship and sponsorship, and optionally identify the nature of involvement of others. Link to GitHub aliases where possible. This list will likely change or grow stage after stage. | ||
|
||
e.g.: | ||
|
||
* @Yasmina | author | ||
* @Monique | sponsor | ||
* @EunJung | subject matter expert | ||
* @JaneDoe | grammar, spelling, prose | ||
* @Mariana | ||
--> | ||
|
||
|
||
## References | ||
|
||
https://github.com/microsoft/mdatp-devicecontrol/blob/main/Removable%20Storage%20Access%20Control%20Samples/macOS/policy/device_control_policy_schema.json | ||
|
||
<!-- Insert any links appropriate to this RFC in this section. --> | ||
|
||
### RFC Pull Requests | ||
|
||
<!-- An RFC should link to the PRs for each of it stage advancements. --> | ||
|
||
* Stage 0: https://github.com/elastic/ecs/pull/2201 | ||
|
||
<!-- | ||
* Stage 1: https://github.com/elastic/ecs/pull/NNN | ||
... | ||
--> |
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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.
volume.action
will be like "attach", "detach", "mount", "unmount". I'm hesitating to place it here. Seemsevent.action
is a better place to save such information. Because these volumes fields will be part of a device event, similar to process events whoseevent.action
can be "start"/"end".thoughts?
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'd also prefer to use the existing
event.action
field over introducing an additional*.action
field, if we can avoid it.