search

ocsf / ocsf-schema

OCSF Schema
Apache License 2.0
625 stars 132 forks source link

Detection Finding has some inconsistencies #893

Open pagbabian-splunk opened 10 months ago

pagbabian-splunk commented 10 months ago

[Note: the public server doesn't have the status_id enums.]

Should finding events (they are events if they are sent as alerts for example) be considered immutable? E.g. if status_id can change, can risk_score change? Or since each is an event, in practice new events would need to refer to the prior events for state changes. Should the correlation_uid be required?

Alternatively (both can be valid), findings as a structure that is mutable can be used by incident management systems, but not as events - they are by definition immutable and the state changes would constitute multiple correlated events.

Additionally:

  1. status_id and activity_id tend to overlap and are maybe redundant: New, In Process, Resolved vs. Create, Update, Close.
  2. Should there be a Delete activity option?
  3. Should there be an Assigned status_id option? And if so, should we include user and group?

Note that the dictionary base class overrides aren't complete, a number of the base class attributes say event, while the overrides say finding.

floydtree commented 10 months ago

[Note: the public server doesn't have the status_id enums.]

Perhaps your filters for recommended fields are unchecked. I can see the enums for status_id field.

Note that the dictionary base class overrides aren't complete, a number of the base class attributes say event, while the overrides say finding.

Right, I have created a PR to address this and simplify a few other definitions - https://github.com/ocsf/ocsf-schema/pull/895

Should finding events (they are events if they are sent as alerts for example) be considered immutable? E.g. if status_id can change, can risk_score change? Or since each is an event, in practice new events would need to refer to the prior events for state changes. Should the correlation_uid be required? Alternatively (both can be valid), findings as a structure that is mutable can be used by incident management systems, but not as events - they are by definition immutable and the state changes would constitute multiple correlated events. Additionally: status_id and activity_id tend to overlap and are maybe redundant: New, In Process, Resolved vs. Create, Update, Close. Should there be a Delete activity option? Should there be an Assigned status_id option? And if so, should we include user and group?

I am glad to say, these points were discussed and debated in the findings group as the classes were being built. To summarize it for you -

The immutability/mutability aspect is left to the implementor, user of the schemas. If implementors have capabilities to provide in-place updates to the finding, they can do so and maintain time identifiers available in the finding_info object throughout the lifecycle, without having to re-write an entire finding for a risk_score, status_id update. For implementors who cannot, they can treat findings as immutable and re-send an entire finding and make use of the finding_info.uid or correlation_uid to establish the relation between the two events.

About status_id and activity_id overlap - it is very much by design. This allows for finding producers to populate activity_id as they generate findings, and consumers to populate statuses as they manage the lifecycle of the findings. Therefore, statuses are not required in the schema.

Further about having user context or an Assigned status, this is where an incident finding would come in. But happy to discuss this point further.

@acockburn @zschmerber if you would like add any additional topics that we had discussed.

pagbabian-splunk commented 10 months ago

The immutability/mutability aspect is left to the implementor, user of the schemas. If implementors have capabilities to provide in-place updates to the finding, they can do so and maintain time identifiers available in the finding_info object throughout the lifecycle, without having to re-write an entire finding for a risk_score, status_id update. For implementors who cannot, they can treat findings as immutable and re-send an entire finding and make use of the finding_info.uid or correlation_uid to establish the relation between the two events.

Great - that was my interpretation but I think we need to be more prescriptive about how to correlate the states of the finding. correlation_uid seems to be the right approach, as it is the general way to tie individual events together (rather than related objects - maybe finding_info_uid has another purpose?).

About status_id and activity_id overlap - it is very much by design. This allows for finding producers to populate activity_id as they generate findings, and consumers to populate statuses as they manage the lifecycle of the findings. Therefore, statuses are not required in the schema.

Ok, makes sense: the producer's view versus the consumer/analyst view. They can share the structure, but the consumer is free to use the structure in a non-event manner, where attributes that were fixed by the producer, can be modified by the consumer (presumably, keeping a record of those changes, such that the 'New' finding is not lost).

Further about having user context or an Assigned status, this is where an incident finding would come in. But happy to discuss this point further.

Yes, it could go either way, but given that we have status change options for the consumer of the finding, we could either tag the assignment within the finding, or we could point to it from an incident envelope. In that case, we should also ship the incident classes with the new detection_finding IMO so we have a complete solution.