Hi folks,
I just got done presenting a webinar on a talk that I was slated to give at Suricon Madrid. Long story short, I ended up getting sick, and having to cancel for Suricon due to severe illness.
OISF offered me a chance to do my talk at a later date through a webinar they hosted, and so here we are.
There are two primary subjects of this talk. the first is exploring the ET_INFO ruleset, and discussing some very useful rules that we utilize in a day to day basis at Proofpoint that often lead to more specific detection signatures for previously unindentified threats.
The second topic is focused on developing network and host-specific artifacts into a set of “Honeytoken IDS rules” that serve as a network or host specific anomaly detection for when these artifacts are exfiltrated, or leave your home network for any reason.
The slide deck, and all of the supporting materials for this talk are available here.
The Webinar was recorded, and should be featured on OISF’s youtube channel sometime soon. This may be the only time I tell anyone to like/comment/subscribe to any youtube channel.
The end of the talk produced some interesting Q and A about some subjects that were covered in the slide deck, and I wanted to make sure that I documented these questions and my answers some place for reference later:
With the suggestion of adding honeytoken IDS rules, rule management becomes a problem. How do you propose managing these new rules?
This is a question that I couldn’t effectively answer during the webinar, because, much like the rules of the ET_INFO ruleset, every single network deployment is different, and what I think is an effective strategy for managing new rules that I think works may not work for you, especially if you use third party solutions or MSSPs to manage your ruleset for you.
-You could create a local web server and include that in suricata-update as a rule source to distribute your honeytoken rules across an IDS fleet
-
You could consider using github for rule version management
-
You could place your rules into jira, or a wiki to help define why the rules exist, and more context as to which machine guids, MAC addresses or IP addresses belong to what hosts (make use of the reference metadata tag to point to your jira/wiki/confluence page that has this information!)
-
You could consider looking into more complex rules using the
pcrexformand/or dataset features for reducing the number of rules, and keeping all of those artifacts into a couple of files.
Your imagination is the limit here.
Do you have any plans for supporting Mitre D3fend and automatic action metadata for the ET ruleset?
So, my important caveat is that I’m not an official spokes person for the ET or Proofpoint. I can say that in the near-term that we don’t have any plans for D3fend, as its still a very new framework. I am not saying that its something that we will NEVER support, but when discussion anything automation actions for what is supposed to be a widely consumed ruleset that is deployed in a variety of ways, that playbooks/automation that serves the needs of EVERYONE is exceedingly difficult.
Another thing I can tell you is that we’re actively improving the metadata tags and metadata for the ruleset that we have currently. Ensuring that Mitre tags are applied where possible, Accurate rule descriptions, more and better references, Severity tags, etc. Shouts to James E.C. for taking the lead with our metadata improvements, and his continued efforts.
Is there are resource that I can refer to that tells me more about the various acronyms and definitions used in the ruleset. What does ET mean? What does TA mean?
“Is there are resource that I can refer to that tells me more about the various acronyms and definitions used in the ruleset. What does ET mean? What does TA mean?”
In terms of our rule categories, we have an excellent post on our community site that tells users more about the purpose a rule category serves over here: Suricata 5, 6, & 7 Rule Categories
More specifically, anytime you see “ET” Assume that it is referring to “Emerging Threats”. For example, “ET OPEN” is the Emerging Threats OPEN Ruleset. “ET PRO” is the Emerging Threats PRO ruleset that is subscription based.
In general with our Ruleset, “TA” stands for “Threat Actor”. So the rule category “TA_Abused_Services” is “Threat Actor Abused Services” – internet services that threat actors have abused previously. If you see TA[number designation] those are rules that are meant to refer to Proofpoint “Threat Actor” Numbers, the threat actor Taxonomy that we use for keeping track of various threat actors.