Emerging Threats is a division of Proofpoint, Inc. Our primary projects are the Emerging Threats Ruleset, contributed and maintained by the security community, and the Emerging Threats Pro Ruleset, which is maintained by the Proofpoint/ET research team, as well as the Emerging Threats Intelligence Product.
Yup. Free, as in BSD licensed, which allows you to do what you like with them. All we ask is that when you have an idea, a new signature, feedback, or even just a theory, that you send it in to benefit everyone.
Any signatures created as a result of Proofpoint research (including malware detonation, global sensor network, integration with other products) go into ETPRO. Any signatures contributed by the community, or signatures that are written by ET/Proofpoint based on community research, go into ET Open. A signature can be migrated from ETPRO to ET Open if a user submits a signatures which has original coverage for an ETPRO signature.
SIDs are always consistent between engines. The message and purpose will be the same across the SID for all of our support rulesets.
If the attributes of a rule undergo changes between supported engines, will the SID for that rule also be different?
No, it will be consistent.
What about rules that are unique to each rule engine? Can we assume that those rules will have unique SIDs and are only relevant to that specific version?
Yes. A SID is our ‘primary key’ for example, and a SID for one engine with one message and purpose will not be changed across engines. If a SID is populated for one engine it will not be re-used with another message and purpose for another engine.
Occasionally a rule performs badly or has the potential to generate false positives but the detection logic is valuable. In this case ET will ship the rule disabled, and you can enable the rule through use of a rule manager such as oinkmaster, pulledpork or suricata-update.
Each rule is created with a TTR (Time-To-Review) value. In that process a rule writer, when creating their rule, has the ability to set the rule to be up for review in 30/60/90 day increments. When the rule is reviewed, it can either be set to be permanent, meaning not to come up for review again, the reviewer can reset the time window to review, or the reviewer can choose to have the rule be disabled.
What are the guidelines for which the ET team might decide to remove a signature based on EOL software?
Only when subsequent revelations have shown a rule was created for a purpose that is no longer accurate is that rule deleted. Rules that are still relevant but perform badly are simply disabled.
What are the guidelines for which the ET team might decide to remove a signature based on an ‘old’ CVE?
CVE rules are not subject to our TTR (Time to Review) process. Exploit-based signatures do not age-out within our automated signature review mechanism. As such, they would only be modified due to the on-the-day judgment of a member of the threat research team based on need. It would be unlikely for them to be disabled.
We use this naming convention when detecting several behaviors of the same malware
- ETPro must be licensed per Sensor instance of Snort or Suricata. The engine type or version does not matter.
- Standard license is an Enterprise license for use to protect an organizations own assets. If a customer would like to include ETPro in a product or service they sell or redistribute to other customers, OEM licensing is available.
- Support is included with base license.
- 1 License per Sensor, where a Sensor is an OS instance
- 5 physical servers running Suricata: 5 Licenses Needed
- 5 VM’s running Suricata on one physical server: 5 Licenses Needed
- 3 Snort processes running on one Physical Server: 1 License Needed
A one-year single-sensor license for ETPRO can be purchased here. Since ETPRO is simply downloaded and installed locally, no customer data is sent back to Proofpoint, streamlining deployment and eliminating PII concerns
There are several methods:
- Ruleset Downloaders like Suricata-Update, Pulled-Pork, OINKMaster
- Your own custom download script
Why is emerging-all.rules not in the tarball (emerging.rules.tar.gz) or the zip (emerging.rules.zip)?
The tarball/zip is intended to be ingested by everything from GUI rule managers to Oinkmaster. The emerging-all.rules has a copy of every rule, all those that are included in each file for each category of rules. If we included -all.rules the rule managers would ingest a duplicate of every sig.
The intent of having emerging-all.rules in the first place is to make a single file download for simplicity. We recommend using the tarball or zip as there are some supporting files in there, but emerging-all.rules will do fine if you just need the rules themselves and don’t need to have them broken into categories by file.