Open MaxwellDPS opened 1 month ago
Hey @MaxwellDPS I've changed the label of your request since it's not a bug per say since it's working as it should, even though, as you have rightfully pointed out, the current logic does not allow you to achieve your use case.
Changing the way we handle SROs can have quite some impact for us and therefore, we need to properly think before tackling this issue instead of providing a a quick fix.
Description
Summarization of SRO's is arguably not following spec, when making a multiple sighting for example I may want to know the exact times that an IP is seen on a System. By rolling the date and counts together all this data is lost and now the object is no longer accurate.
SRO's need to be treated as time series data not sumeries otherwise most investigative value is lost. By summarizing this data it destroys any practical timeline that can be constructed
By dropping this metadata its not really tracking an instance of a thing, but a summary (This applies too for all SROs)
Example
Take the following STIX objects come in for this example
Given this the platform is going to display one entry like:
1 sighting of 1.1.1.1 to system-x with a count of 70 starting at 04/20/22 00:05:00 and ending at 10/10/24 01:01:00
This is meaningless to any one working an incident when the timeline is destroyed. How many actual times was this seen on 10/10/24, was it 69 between 10/10/24 01:00:00 -> 10/10/24 01:01:00? Who knows anymore 🤷
Another example
assume you are tracking logins as a located-at with labels. If I want to display the following:
Given this the platform is going to display one entry like:
User max in Seattle between 11/10/22 01:00:00 -> 11/12/22 12:00:00 while also in portland sometime on 11/11 - So when was user max last seen on 11/10/22? Who knows anymore 🤷
Environment