Add additional process fields from ECS #993
Conversation
Added fields: * `process.args_count` * `process.title` * `process.uptime` * `process.working_directory`
| @@ -15,6 +15,7 @@ An operating system process. | |||
|
|
|||
| | Attribute | Type | Description | Examples | Stability | | |||
| | ----------------------------- | -------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------- | ---------------------------------------------------------------- | | |||
| | `process.args_count` | int | Length of the process.command_args array [1] | `4` |  | | |||
There was a problem hiding this comment.
This is also more like a metric, no? 🤔
There was a problem hiding this comment.
This could be a metric, but to me, it doesn't feel like it should. I don't think it represents any measurement that anyone would care to track over time with a metric. The arg_count generally won't change (outside of an exec), and it's not a measurement that indicates system performance or utilization.
It does have value as an attribute in a log/event though. This is intended to be a convenience/performance field. You could also get arg count by counting the process.args length, but having a separate arg_count field makes it easier to write queries on this field directly.
There was a problem hiding this comment.
The arg_count generally won't change (outside of an exec), and it's not a measurement that indicates system performance or utilization.
Hum, but this then contradicts the brief of the field, no?
This field can be useful for querying or performing bucket analysis on how many
arguments were provided to start a process. More arguments may be an indication
of suspicious activity.
If it's important to recognize suspicious activity like that, I feel having it in a log or span, rather than being a metric is more cumbersome? Because one would have to extract the attribute from logs/spans and then plot it somehow as a metric?
There was a problem hiding this comment.
I've talked with the team at Elastic that uses this field to work on detections, and they've told me it has value as both a metric and an attribute attached to an event.
I've now added it as both a metric and a field in the attribute registry in this PR. Although I didn't see any prior art for a field being used as both, so I'm not sure if I've done it in the correct way
There was a problem hiding this comment.
Hum I'm also not sure, having both the attribute and the metric seems a bit.. unnecessary but I don't have strong opinions against it. I left another comment because you used a Histogram for it and I'm not sure why.
model/metrics/process-metrics.yaml
Outdated
| metric_name: process.args_count | ||
| stability: experimental | ||
| brief: "Number of process arguments." | ||
| instrument: histogram |
There was a problem hiding this comment.
Was there any particular reason to use a histogram here?
There was a problem hiding this comment.
I chose histogram because this is a non-additive property, and according to this, the only metric instruments to use for non-additive properties are Histogram and Asynchronous gauge. Of these two, I think the histogram is better, since there's value in working with the statistics of args_count. For example, an outlier in the number of arguments for a process name could be an indication of attack.
If there's another instrument type you think is better, I will change it. I don't know the metric instrument types well, and if there's something more appropriate I can change it.
model/metrics/process-metrics.yaml
Outdated
|
|
||
| - id: metric.process.args_count | ||
| type: metric | ||
| metric_name: process.args_count |
There was a problem hiding this comment.
what would be the use case for this metric? Does it make any sense, especially without any attributes?
I.e. I can see P95 of my processes have 2 arguments and P99 is 10 arguments - is this helpful at all?
There was a problem hiding this comment.
I've taken args_count out for now. This is useful for threat hunting, but it's really not useful for system performance or other use cases.
In the future we can consider adding it back in a more use-case specific metrics namespace.
Changes
Add additional process fields to the attribute registry, from ECS.
The newly added fields are:
Merge requirement checklist
[chore][ ] schema-next.yaml updated with changes to existing conventions.