You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
stix-shifter "to_stix_map" mappings are currently "dumb", meaning that they map a native result field to a STIX property regardless of any sort of context. This causes problems sometimes, like with QRadar always creating a network-traffic object (as shown in #205 (comment)).
Describe the solution you'd like
Each mapping could support a "condition" field where the conditions required for the mapping to be valid are described with simple boolean logic. No "condition" field would mean the mapping is always valid, in order to maintain backwards compatibility.
As an example, QRadar's "sourceip" field could be mapped like this:
I've added the "condition" to the network-traffic.src_ref mapping. Without the condition, every QRadar result will create a network-traffic object, event if the event is not describing an actual network connection. In the example, a network-traffic object would only get created for certain Windows events that correspond to actual network connections being made.
This example is only for illustration, because it's specific to Windows events. For the real QRadar mapping, QRadar high-level categories should probably be used as suggested in #205.
Describe alternatives you've considered
I don't have any alternatives at the moment.
Additional context
N/A
The text was updated successfully, but these errors were encountered:
A possible additional use case is for network-traffic:start: if the native event is indicating that a network connection is being created, we could then use the event's timestamp as network-traffic:start (instead of just the observed-data SDO's first_observed timestamp). The benefit here is that in STIX 2.1, start is an "ID contributing property" and is used to create the id property for network-traffic. This might help avoid id collisions when 2 hosts make repeated connections and ports get reused.
Is your feature request related to a problem? Please describe.
stix-shifter "to_stix_map" mappings are currently "dumb", meaning that they map a native result field to a STIX property regardless of any sort of context. This causes problems sometimes, like with QRadar always creating a
network-traffic
object (as shown in #205 (comment)).Describe the solution you'd like
Each mapping could support a "condition" field where the conditions required for the mapping to be valid are described with simple boolean logic. No "condition" field would mean the mapping is always valid, in order to maintain backwards compatibility.
As an example, QRadar's "sourceip" field could be mapped like this:
I've added the "condition" to the
network-traffic.src_ref
mapping. Without the condition, every QRadar result will create anetwork-traffic
object, event if the event is not describing an actual network connection. In the example, anetwork-traffic
object would only get created for certain Windows events that correspond to actual network connections being made.This example is only for illustration, because it's specific to Windows events. For the real QRadar mapping, QRadar high-level categories should probably be used as suggested in #205.
Describe alternatives you've considered
I don't have any alternatives at the moment.
Additional context
N/A
The text was updated successfully, but these errors were encountered: