Risk Fields #518
Risk Fields #518
Conversation
Added nested risk fields for logging individual event risk scores based on users/groups/hosts/cloud/container/data/threats/vulnerabilities
schemas/risk.yml
Outdated
| level: extended | ||
| type: keyword | ||
| description: MD5 hash. | ||
| description: locally relevant label to describe the risk type of asset or data identified either |
There was a problem hiding this comment.
Can we enhance this definition to make it clearer to those transforming data what they should put here? What is the relationship of this field value to the risk.score? Do we expect this to be an array, holding multiple values?
There was a problem hiding this comment.
An array could be helpful, certainly I can see applying PCI & IAM or PCI & Security, etc.
schemas/risk.yml
Outdated
| level: extended | ||
| type: keyword | ||
| description: SHA512 hash. | ||
| example: 1-10 |
There was a problem hiding this comment.
Is this really just an example, or should we define this must contain a 0-10 value? At the least, we should recommend a 0-10 scoring system.
There was a problem hiding this comment.
I think all the scores should be 0-10, matches all of the existing CVE/CVSS etc.
There was a problem hiding this comment.
It might help to consider how we would apply asset / resource risk levels to a normalized scoring system to prioritize signals by business risk - tho I suppose we could allow for multiples.
|
I think my gitFoo has failed me...
the hashes shouldn't be there... will verify and update the label field to
something else
…On Tue, Aug 13, 2019 at 10:00 AM Mike Paquette ***@***.***> wrote:
***@***.**** commented on this pull request.
Not sure about the event.risk.score algorithm should be specified here.
Also, dropped a few comments.
------------------------------
In schemas/risk.yml
<#518 (comment)>:
>
fields:
- - name: md5
+ - name: label
@dainperkins <https://github.com/dainperkins> Is there another name we
could use instead of "label" ? As you know, one ECS base field is "labels"
(plural), but I am worried about creating confusion, so I wonder if we
could use something like .name to be consistent with other field sets?
------------------------------
In schemas/risk.yml
<#518 (comment)>:
> level: extended
type: keyword
- description: MD5 hash.
+ description: locally relevant label to describe the risk type of asset or data identified either
Can we enhance this definition to make it clearer to those transforming
data what they should put here? What is the relationship of this field
value to the risk.score? Do we expect this to be an array, holding
multiple values?
------------------------------
In schemas/risk.yml
<#518 (comment)>:
>
- - name: sha512
- level: extended
- type: keyword
- description: SHA512 hash.
+ example: 1-10
Is this really just an example, or should we define this must contain a
0-10 value? At the least, we should recommend a 0-10 scoring system.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#518?email_source=notifications&email_token=AJMZFSLN6BXVDKXVBKO37FDQEK463A5CNFSM4ILGUBGKYY3PNVWWK3TUL52HS4DFWFIHK3DMKJSXC5LFON2FEZLWNFSXPKTDN5WW2ZLOORPWSZGOCBMXKFY#pullrequestreview-274298135>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AJMZFSOL4OY6A6WB6WHWUMDQEK463ANCNFSM4ILGUBGA>
.
|
|
@MikePaquette Array throws an error when I try to run make (I think @webmat said something about that previously) so I left it as keyword. Do you still think there needs to be more in terms of usage of risk.tag? Trying to allow for whatever makes the most sense in any given environment, actually now that I think of it, event.risk.tag could easily be a concatenation of the individual risk tags from user/group/ips/file, etc. |
updated Risk Fields
|
@dainperkins thanks for making the change. I do like the concept of "tags" being added to a risk field at various points, and possibly aggregating them in From a field naming perspective Question: With this change (adding Or do we keep I continue to lean toward specifying the numeric scale for |
|
Question: With this change (adding risk.* fields), are you suggesting
that we deprecate current ECS fields event.risk_score and/or
event.risk_score_norm ?
While i hadn't previously considered it, I think I am suggesting
deprecating risk_score / risk_score norm in favor of a single reusable risk
field set that can represent both atomic entity risk factors (user, group,
asset, threat, ioc lookups, etc.) as well as the normalized risk of an
event (based on atomic risk scores of available entities , or signal (based
on normalized atomic *event* risk scores)
That being said, it does seem like a non-normalized representation (e.g. PA
uses low, medium, high, very high, critical or something iirc, firepower
something similar) and we should have a spot for risk scores as reported
add risk.original or risk.reported to the risk fields?
or
leave event.risk_score as the original risk label (quantitative or
qualitative) for searching on risks from a specific device standpoint (e.g.
show me everything PA labeled a high risk)
/d
…On Wed, Aug 28, 2019 at 7:26 AM Mike Paquette ***@***.***> wrote:
@dainperkins <https://github.com/dainperkins> thanks for making the
change. I do like the concept of "tags" being added to a risk field at
various points, and possibly aggregating them in event.risk.tag.
From a field naming perspective .tag has a similar potential for
confusion, this time with the ECS tags field. Would like @webmat
<https://github.com/webmat> to weigh in with his thoughts on whether this
is a significant concern.
Question: With this change (adding risk.* fields), are you suggesting
that we deprecate current ECS fields event.risk_score and/or
event.risk_score_norm ?
Or do we keep event.risk_score_norm as defined, as a 0 to 100 scale of
risk associated with the event? That way, application developers can build
"aggregate risk" logic and visualizations based on the
event.risk_score_norm field, but it will be up to the users to populate
the underlying *.risk.score fields based on their environment.
I continue to lean toward specifying the numeric scale for risk.score in
the ECS field definition.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#518?email_source=notifications&email_token=AJMZFSM5IGO42OYRERHUBQTQGZOG5A5CNFSM4ILGUBGKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD5KZILQ#issuecomment-525702190>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AJMZFSN6NV5ZPJMC7DM6GILQGZOG5ANCNFSM4ILGUBGA>
.
|
|
@MikePaquette How about risk.scope (thinking of PCI in scope / out of scope from an Audit perspective instead of tag/label I think pulling risk fields out of nesting with event makes more sense - that way theres a specific place for event risk (e.g. palo says this is a high risk alert) as well as normalized_risk for business level sorting of signals (which combines signal risk with some d&d style modifier based on assets, users, zones, etc... |
removed "event." nesting renamed risk.tag to risk.scope updated text
removed event nesting changed .tag to .scope updated text, etc
|
@dainperkins We're going to close this out for now as it's been opened for a while without activity. If you want to move forward, let's open a stage 0 RFC proposal to capture these ideas. |
Added risk fields for scoring and categorizing atomic users / groups / hosts / cloud / containers etc.