feat: Cisco Secure Firewall SnortML GID411 and dual-signal corroboration samples

[AAH20]

Details

Adds unit-test datasets for dual-signal triage:

• `intrusion_event_snortml/` — IntrusionEvent samples with `GeneratorID=411` (SnortML ML-only)
• `dual_signal_corroboration/` — paired classic Snort intrusion + high EVE ConnectionEvent sharing `ConnectionID`

Supports ESCU detections proposed in splunk/security_content#4220

Notes

• Synthetic / documentation-range IPs only
• CLA: will confirm signature on the linked security_content issue before merge

Made with Cursor

[AAH20]

CLA: signed (same contributor as security_content #4221 / issue #4220).

[nasbench]

The log files have to be uploaded as lfs, and a corresponding yaml file needs to be provided. Please check out other entries in this repo for reference.
Here is the template for the YAML - https://github.com/splunk/attack_data/blob/master/datasets/TEMPLATE.yml

Also to me these seems like fake log. Were these generated by evidence forge?

Since I am seeing an EVE but no fingerprint for example, the URL field is missing for connection events, also the initiator port is reversed seeing that this is HTTP traffic.

This looks like slop to me :)

[AAH20]

@nasbench Fair callout, and correct on every point — I checked each one against this repo's own real reference data (datasets/cisco_secure_firewall_threat_defense/connection_event/connection_events.log, which you authored) rather than taking your word for it, and confirmed:

• Ports were reversed. InitiatorPort had 443 and ResponderPort had the high port — backwards for a client-initiated HTTPS connection. Fixed on every entry in both files (initiator now has the ephemeral port, responder has 443).
• EVE_Fingerprint was missing despite the record claiming Encrypted Visibility Engine detection (ClientAppDetector: "Encrypted Visibility", EVE_Process). EVE detection is keyed on the TLS ClientHello fingerprint — a record can't claim EVE without one. Added, plus the SSL_* fields (CertFingerprint, CipherSuite, FlowStatus, Version, ServerCertStatus, ActualAction, ExpectedAction) that accompany it in every real EVE-tagged connection event in this repo.
• URL was missing. Added.
• LFS + YAML: the .log files were committed as plain blobs instead of going through LFS per .gitattributes, and there was no dataset .yml. Fixed — re-committed through LFS, added .yml metadata matching the convention every sibling cisco_secure_firewall_threat_defense dataset uses (I used react2shell.yml/static_tundra.yml as the template), removed the ad hoc README.mds.

On "slop" — you're right that it was. Reversed ports on synthetic data is exactly the kind of thing that only survives if nobody checked it against a real capture or a real reference in the same repo, and I hadn't. I have now, and the specific numbers above are why I'm not going to push back on the assessment. Ready for another look.