Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Conditional mappings #1362

Open
pcoccoli opened this issue Mar 4, 2023 · 1 comment
Open

Conditional mappings #1362

pcoccoli opened this issue Mar 4, 2023 · 1 comment
Labels
enhancement New feature or request

Comments

@pcoccoli
Copy link
Contributor

pcoccoli commented Mar 4, 2023

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:

    "sourceip": [
        {
            "key": "ipv4-addr.value",
            "object": "src_ip"
        },
        {
            "key": "ipv6-addr.value",
            "object": "src_ip"
        },
        {
            "key": "network-traffic.src_ref",
            "object": "nt",
            "references": "src_ip",
            "condition": {
                "any": [
                    "all": [
                        {
                            "field": "logsourcetypename",
                            "op": "=",
                            "value": "Microsoft-Windows-Sysmon"
                        },
                        {
                            "field": "EventID",
                            "op": "=",
                            "value": 3
                        }
                    ],
                    "all": [
                        {
                            "field": "logsourcetypename",
                            "op": "=",
                            "value": "Microsoft-Windows-Security-Auditing"
                        },
                        {
                            "field": "EventID",
                            "op": "=",
                            "value": 5156
                        }
                    ]
                ]
            }

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

@pcoccoli pcoccoli added the enhancement New feature or request label Mar 4, 2023
@pcoccoli
Copy link
Contributor Author

pcoccoli commented Mar 4, 2023

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

1 participant