Detection Finding and finding_info need clarifications and removal of malware, addition of a verdict.

[pagbabian-splunk]

1. The class and the finding_info object both have a time range. finding_info has first_seen, last_seen, 'modified_timewhich is confusing since a finding is something created at a moment in time, and optionally, the potential for it to be modified, perhaps in a management system. I'm not sure what it means to first see it, or last see it. Is it trying to capture the originaltimeinfirst_seenafter modifications, which may arrive as events with differenttimevalues, but still different thanmodified_time? And what is 'last_seen mean?
2. It brings up the question of mutability of a finding. Certain attributes, such as status_id can have different values for the same finding, but reported with different events. Are these the range of timestamps that should be populated within finding_info's first_seen and last_seen timestamps, while modified_time is when the finding was enriched? Are these mostly targeted at the other Findings classes (e.g. Vulnerability Findings)? Needs to be made more clear.
3. start_time and end_time in the class are clear - they refer to the range of contributing events that were behind the finding.
4. finding_info has a uid attribute that points to the finding. The implication is that the instance of finding_info can exist outside of the instance of the class (e.g. in a list within an Incident event). If so, then the pointer needs to be present at the class level as well. Presumably this is the metadata.uid attribute. We should call it out as such.
5. There is no indication of what the verdict of a finding is, just it's state (e.g. resolved) and severity (e.g. Informational).
6. security_control should be applicable but only when the finding is produced by a control, not by a backend analysis that doesn't have the enforcement point power of 'allow' or 'deny' and therefore cannot carry the disposition_id of security_control. Nevertheless, a verdict should be present (e.g. False Positive, Suspicious, Malicious, etc.).
7. The finding can be generated either by a security control (e.g. an anti-malware endpoint product) or a backend analysis system (e.g. a SIEM or a SOC analyst). We should indicate what type of system produced the finding (e.g. control or analysis). Related, the analytic attribute of finding_info may not be populated by a security control, but should be populated by a backend analysis system.
8. While a security control can detect malware, and impart MITRE TTPs, a back end analysis likely can only impart the TTPs. Therefore malware should be delegated to security_control and removed from the class. (It could be determined within an Incident, which could refer to findings that were also produced by a security control, as well as a backend analysis).
9. security_control will add malware AND attacks the latter also being copied in finding_info. Given one purpose of finding_info is to carry the summary of the finding outside of the instance of the class (e.g. a copy of it within Incident, pointing back to the instance of the class), it should be called out that both SHOULD be populated in the case where security_control has been applied.
10. Lastly, we should deliver the Incident class at the same time as the detection_finding class so that the solution is not left incomplete (e.g. if any of the attributes such as a suggested verdict belong in the Incident vs. the detection_finding.

[zschmerber]

1-3 Will need to be addressed with updated descriptions
4. Yes this will point to the metadata.uid
5. Lets make a verdict field in the top level of the finding called Verdict e.g. False Positive, Suspicious, Malicious, etc.
6-7 Agree with this observation
8. Remove malware from the base and add via SC profile
9. When there is a collision we will have to point the analyst or mapper to the description
10. Verdict should be in Incident only. (security control will not be in Incident)

[zschmerber]

Closing this issue, all PRs have been Merged to fix this issue.