Last year I priced network detection for a security operations center (SOC) in a greenfield build. The Talos Subscriber ruleset came in at $399 per sensor per year for business use, and Emerging Threats (ET) Open sat next to it at zero.
When a production ET Open deployment showed tens of thousands of rules with only a fraction on by default, I realized that purchasing was the easy part but curation was the real job.
Borrow rules only from actively maintained sources and categories with defensible signal-to-noise, and validate each rule against real packet captures (PCAPs) before production.
In brief:
- Free doesn't mean current: Talos Registered lags Subscriber by 30 days and generally doesn't get the zero-day set, while ET Open has no equivalent gate.
- A conservative start is Talos's Balanced policy plus a few ET Open categories you can validate locally.
- A rule that passes snort2lua conversion can be syntactically correct and still detect nothing, and syntax checking won't catch it.
- For a greenfield SOC in 2026 without Cisco FTD, the rules worth borrowing are Snort-format, but the engine running them is likely Suricata.
What borrowing a Snort rule actually means
A sample Snort rule is a published signature, header plus options, that you copy into your ruleset to match a known-bad pattern on the wire. That is the textbook definition, and the problem it hides is that signature supply is abundant.
Community rulesets are intentionally larger than any single deployment should run, and every borrowed rule carries an expiry date you don't control.
The maintenance liability is the point. When a malware family moves its command-and-control endpoints, the rules matched to the old ones stop firing and have to be rewritten, so a borrowed rule pays off only while the threat behavior holds still.
Four decisions hide inside "borrowing rules," and they're separate. The engine (Snort 3 or Suricata) sets parsing and performance, and the content source (the Talos tiers, ET Open, or custom rules) sets availability and licensing. The policy baseline sets alert volume, and every custom rule needs version control, test traffic, an owner, and a retirement date.
Talos and ET Open solve different problems, and the 30-day lag is the catch
When I compare rule sources, I score four things: cost, update delay, cadence, and default noise. Talos Community is free with no registration. Talos Registered is free but requires registration and runs 30 days behind the Subscriber set. Talos Subscriber costs $29.99 per sensor per year for personal use or $399 for business, with rules available immediately on release.
ET Open is free under a BSD license and stays actively maintained, with no 30-day gate.
The Registered lag is worse than it sounds. The Registered set excludes new content produced during the 30-day window, and the zero-day Limited Ruleset generally isn't distributed to Registered users. Run the Community ruleset alongside Registered to compensate.
Unless you're paying for Subscriber, layer ET Open on top of the free Talos tier, since ET Open has no equivalent gate.
Start with Balanced and a few validated ET categories
For the Snort Subscriber Ruleset, Balanced is the recommended initial policy, and it's the right starting point for a new SOC.
Balanced includes rules with a Common Vulnerability Scoring System (CVSS) score of 9 or higher from Common Vulnerabilities and Exposures (CVEs) in the current year and the two prior years, plus every rule in the MALWARE-CNC, BLACKLIST, SQL-INJECTION, and EXPLOIT-KIT categories. Those categories map most directly to active compromise.
At the other end, Talos's Maximum Detection policy is security-first and expects false positives and performance impact, so it belongs in testing rather than production. For ET Open, I'd apply the same rule: don't enable every category, because many are noisy.
The categories below are pilot candidates, not a universal baseline. Signal-to-noise depends on your shared infrastructure, cloud workloads, NAT, SaaS, and DNS or proxy design, so validate each in IDS-only mode before trusting it.
- Pilot first: botcc, compromised, dshield, malware, trojan
- Add with tuning: exploit_kit, and dns only where the sensor sees plaintext DNS
- Leave off: info, dyn_dns, and retired (retired rules are obsolete or replaced, not merely low priority)
One untuned deployment I saw was firing far more alerts than any analyst team could triage. That's why community rulesets ship many rules disabled: the detection logic is valuable but false-positive-prone.
Four sample Snort rules to study and validate, not just deploy
These four cover Server Message Block (SMB) lateral movement, credential dumping, executable delivery, and Domain Name System (DNS) tunneling. They're useful for reading rule structure and as test candidates, but they're older, tool-specific signatures whose value depends on your traffic visibility, encryption, and sensor placement.
Validate each against true-positive and normal-traffic PCAPs before trusting it, and confirm the current SID and rule text against the live ET distribution, because revisions and IDs change.
PowerShell with hidden window over SMB (ET, SID 2025720)
This rule matches a Unicode (UTF-16LE) powershell string plus a -hidden argument in inspectable SMB traffic to port 445, a PowerShell execution technique in MITRE ATT&CK, identified here by signature ID (SID) 2025720. Treat it as a contextual signal, not proof of lateral movement:
it can fire on legitimate remote administration, and it's blind to encrypted SMB, alternate encodings, and endpoint-to-endpoint traffic off the sensor's path.
Correlate it with endpoint process activity, remote authentication, and admin allowlists before escalating.
The rule (verify the SID against the current ET set):
alert smb any any -> $HOME_NET 445 (msg:"ET POLICY Powershell Command With Hidden Window Argument Over SMB - Likely Lateral Movement"; flow:established,to_server; content:"SMB"; depth:8; content:"|00|p|00|o|00|w|00|e|00|r|00|s|00|h|00|e|00|l|00|l|00|"; nocase; distance:0; fast_pattern; content:"|0000|w|00|"; nocase; distance:0; content:"|00|h|00|i|00|d|00|d|00|e|00|n|00|"; nocase; distance:0; classtype:trojan-activity; sid:2025720; rev:3; metadata:attack_target SMB_Client, created_at 2018_07_17, deployment Perimeter, deployment Internal, former_category POLICY, performance_impact Low, signature_severity Major, updated_at 2018_07_18;)
Pwdump6 credential dumping over SMB (ET, SID 2008445)
The hex sequence is a Unicode representation of the filename test.pwd, a heuristic for one credential-dumping tool. It's a legacy, tool-specific signature, useful as rule anatomy rather than a modern credential-access detection.
Endpoint telemetry such as LSASS access, dump-file creation, suspicious service creation, and authentication correlation covers this behavior far more reliably. The rule:
alert tcp any any -> $HOME_NET [139,445] (msg:"ET EXPLOIT Pwdump6 Session Established test file created on victim"; flow:to_server,established; content:"|5c 00 74 00 65 00 73 00 74 00 2e 00 70 00 77 00 64|"; reference:url,xinn.org/Snort-pwdump6.html; reference:url,doc.emergingthreats.net/bin/view/Main/2008445; classtype:suspicious-filename-detect; sid:2008445; rev:3;)
PE/DLL file download (ET, SID 2000419)
This rule matches the MZ DOS magic bytes, then uses byte_jump to find and confirm the PE\x00\x00 header, so it can identify a visible Windows Portable Executable or dynamic-link library (DLL) transfer regardless of file extension. Treat the alert as executable-transfer telemetry, not malware detection:
it can't see encrypted traffic, unsupported transports, or flows the sensor can't reassemble, and it needs tuning for approved software distribution and patching.
The rule:
alert tcp $EXTERNAL_NET any -> $HOME_NET any (msg:"ET POLICY PE EXE or DLL Windows file download"; flow:established,to_client; content:"MZ"; byte_jump:4,58,relative,little; content:"PE|00 00|"; distance:-64; within:4; flowbits:set,ET.http.binary; reference:url,doc.emergingthreats.net/bin/view/Main/2000419; classtype:policy-violation; sid:2000419; rev:22;)
NSTX DNS tunneling (GIAC-documented, SID 10002)
The rule uses three content matches: a DNS header flags value for a standard recursive query at bytes 2-3, the NSTX-specific cT marker at offset 12, and the TXT record type NSTX uses for exfiltration. It's a historical, tool-specific NSTX signature, not broad DNS-tunneling coverage.
A modern approach layers subdomain entropy and length, unique-subdomain volume per domain, rare parent domains, uncommon record-type volume, and queries bypassing approved resolvers.
The GIAC-documented rule:
alert udp $EXTERNAL_NET any -> $HOME_NET 53 (msg:"Potential NSTX DNS Tunneling"; content:"|01 00|"; offset:2; within:4; content:"cT"; offset:12; depth:3; content:"|00 10 00 01|"; within:255; classtype:bad-unknown; sid:10002;)
What I couldn't borrow: Cobalt Strike coverage
Talos ships Cobalt Strike detection, but the full rule text sits in the paywalled Subscriber ruleset. ET Open covers some Malleable C2 profiles for free. Confirm the exact SIDs and profile coverage against the current Talos and ET documentation before relying on either.
Conversion is not validation
If you're porting borrowed rules to Snort 3, a successful conversion doesn't prove the rule still detects the same traffic. The risk is changed rule semantics: sticky buffers, protocol inspectors, and option behavior differ from Snort 2, so a syntactically valid converted rule can end up inspecting the wrong data.
Use snort2lua for the initial conversion, then manually review and test the high-priority, buffer-dependent, thresholded, or suppressed rules.
snort2lua can emit event_filter configuration from a threshold, but that output may land separately and has to be included and tested, and rules with thresholds or suppressions often need to be recreated.
PCAP testing with Dalton is the backstop, alongside config validation, staging sensors, and post-deploy review: it runs PCAPs against a Snort or Suricata sensor with your exact ruleset. One caveat trips up first-timers: most TCP rules require established sessions, so a single-packet PCAP won't fire them.
Build full-session captures, and treat any migrated rule that hasn't alerted on a known-true-positive PCAP as unconverted.
Treat every suppression as a detection you're choosing to give up
event_filter rate limiting applies to a SID (one event per 60 seconds per source, say), and suppress scopes a rule away from a specific IP or Classless Inter-Domain Routing (CIDR) block rather than killing it globally. The mistakes are just as well known:
most rules are conditional on HOME_NET and EXTERNAL_NET, so setting HOME_NET to any removes the internal/external boundary many rules rely on.
Run an intrusion detection system (IDS) in alert-only mode for weeks before any rule blocks anything.
One detection lead pulled six months of history on a noisy rule and found exactly one true positive: the early recon phase of a paid red team engagement. Disabling it would have deleted the only working detection for that behavior.
So every suppression gets documented with the MITRE ATT&CK technique it affects and reviewed on a schedule, because the suppression file is a running list of detection you've agreed to give up.
Borrow the rules, but question the engine
For a greenfield deployment in 2026, I'd run Snort-format rules in Suricata. ET maintains its ruleset in Suricata-native format, ET Pro supports Suricata, and one academic comparison, under its own corpus and rule versions, found Suricata detected more attacks than Snort 3.
Portability runs one way: many Snort 2-style rules work in Suricata after review, but Snort 3 rules aren't directly compatible, and OISF has no official conversion tool planned.
If you're inside Cisco's Firepower Threat Defense (FTD) ecosystem or carrying a large Snort 3 custom library, Snort 3 is the right call, and its multithreading has come a long way from Snort 2's single thread.
But if I were signing the greenfield build order today, I'd borrow the Snort-format rules above and point them at Suricata 8.0.6, the current 8.0 release as of August 31, 2026.
Run the borrow-and-validate loop this week
The concrete next step fits in one week. Stand up a sensor in IDS-only mode, load the Balanced policy or the five ET categories, add the four rules above, then replay full-session true-positive PCAPs through Dalton and count what fires and what stays silent.
I've signed enough ruleset renewals to know that an unvalidated borrowed rule sitting quiet in production, while the team assumes it's working, costs more than the $399 sensor license.
Frequently asked questions about sample Snort rules
What's the difference between Snort community, registered, and subscriber rules?
Community rules are free with no registration. Registered rules are free but run 30 days behind the Subscriber set, and the zero-day Limited Ruleset generally isn't distributed to Registered users. Subscriber costs $29.99 per sensor per year for personal use or $399 for business, with rules available immediately on release.
Which Emerging Threats Open categories should I turn on first?
Pilot botcc, compromised, dshield, malware, and trojan first, validating each locally, since signal-to-noise depends on your network. Add exploit_kit and dns once you have tuning capacity, and dns only where the sensor sees plaintext DNS. Leave info, dyn_dns, and retired off; retired rules are obsolete or replaced.
Do Snort 2 rules work in Snort 3?
Not reliably without manual review. A converted rule can be syntactically correct and still inspect the wrong data, because Snort 3's sticky buffers and inspectors differ from Snort 2. Convert with snort2lua, then review and test buffer-dependent, thresholded, and suppressed rules against known PCAPs, since those often need to be recreated.
Should a new SOC use Snort or Suricata in 2026?
For greenfield deployments without Cisco FTD infrastructure, Suricata is usually the better fit: it runs ET Open natively, scales on a single multithreaded instance, and has industrial control system (ICS) protocol parsers. One academic comparison found it detected more attacks than Snort 3, though under a single corpus and rule version.
Snort 3 remains the right choice inside Cisco's ecosystem or where large Snort 3 rule libraries already exist.
How do I test Snort rules before deploying them to production?
Run true-positive and false-positive PCAPs against your exact ruleset with Dalton. Use full-session captures, because most TCP rules only fire on established sessions. Put rules in version control with a config test gating merges, and run new rules in IDS-only mode for a few weeks before allowing any of them to block.