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
{{ message }}
This repository was archived by the owner on Jul 9, 2026. It is now read-only.
Repository navigation
This repository was archived by the owner on Jul 9, 2026. It is now read-only.
Issue discovered when translating the OUO field from a CFM13 file. Translation is from cfm13 to lqmtools schema. The OUO field maps to the sensitivity field in the lqmtools schema.
The CFM13 file in question has multiple indicators in said file. When there are multiple indicators with OUO values set to the same value (ex: OUO = 1 or OUO = 0) there is no issue, but the moment the chain is broken all of the resulting sensitivity fields are marked as noSensitivity in the resulting translations. Example below
Working block in short-hand:
additional data -- type="integer" -- meaning="OUO" value=1
...
additional data -- type="integer" -- meaning="OUO" value=1
...
additional data -- type="integer" -- meaning="OUO" value=1 result:
action1, sensitivity
block, OUO
block, OUO
block, OUO
Just ran a test against this with an input of cfm13alert (modified from test case) and output of lqmt, and I'm getting expected values. Starting with an input w/ 3 alerts, and sensitivity of ouo/noSensitivity/ouo, I achieve the expected results
Note: In my testing, I found if you're ingesting a metadata file along with the CFM13Alert, it should override all values to the value found in the CFM13Alert file.
The metadata file (envelope) should only be used to set values (sensitivity, recon, etc.) when not present in an alert. In other words, the precedence order should be (highest to lowest): internal, metadata (envelope), defaults.
Appreciate the clarification Dan. Just confirmed all the alerts I was running to get this bug were using Metadata files that specified the sensitivity.
I'll look into changing how we handle metadata files. I'm thinking the original use-case for them was pretty limited, so I'll want to review & go over new use-cases that before changing anything.
Activity
mghenderson commentedon Jul 4, 2016
Just ran a test against this with an input of cfm13alert (modified from test case) and output of lqmt, and I'm getting expected values. Starting with an input w/ 3 alerts, and sensitivity of ouo/noSensitivity/ouo, I achieve the expected results
Note: In my testing, I found if you're ingesting a metadata file along with the CFM13Alert, it should override all values to the value found in the CFM13Alert file.
Input File:
Output:
[ { "action1": "Block", "comment": "SSH scans against multiple hosts, direction:ingress, confidence:87, severity:high", "detectedTime": 1456116353.0, "directSource": "Fake", "duration1": "86400", "fileHasMore": "0", "indicator": "5.5.5.5", "indicatorType": "IPv4Address", "majorTags": "Scanning", "priors": "11", "processedTime": "1467671787", "reason1": "SSH Attack", "reconAllowed": "0", "reference1": "user-specific", "restriction": "WHITE", "sensitivity": "ouo" }, { "action1": "Block", "comment": "SSH scans against multiple hosts, direction:ingress, confidence:87, severity:high", "detectedTime": 1456116353.0, "directSource": "Fake", "duration1": "86400", "fileHasMore": "0", "indicator": "10.10.10.10", "indicatorType": "IPv4Address", "majorTags": "Scanning", "priors": "11", "processedTime": "1467671787", "reason1": "SSH Attack", "reconAllowed": "1", "reference1": "user-specific", "restriction": "AMBER", "sensitivity": "noSensitivity" }, { "action1": "Block", "comment": "SSH scans against multiple hosts, direction:ingress, confidence:87, severity:high", "detectedTime": 1456116353.0, "directSource": "Fake", "duration1": "86400", "fileHasMore": "0", "indicator": "20.20.20.20", "indicatorType": "IPv4Address", "majorTags": "Scanning", "priors": "11", "processedTime": "1467671787", "reason1": "SSH Attack", "reconAllowed": "1", "reference1": "user-specific", "restriction": "AMBER", "sensitivity": "ouo" } ]dharknessANL commentedon Jul 5, 2016
The metadata file (envelope) should only be used to set values (sensitivity, recon, etc.) when not present in an alert. In other words, the precedence order should be (highest to lowest): internal, metadata (envelope), defaults.
smsullivan commentedon Jul 5, 2016
Appreciate the clarification Dan. Just confirmed all the alerts I was running to get this bug were using Metadata files that specified the sensitivity.
mghenderson commentedon Jul 5, 2016
I'll look into changing how we handle metadata files. I'm thinking the original use-case for them was pretty limited, so I'll want to review & go over new use-cases that before changing anything.