Naming queries

[shannaniggans]

So in order to stop me spending 2 weeks on what to name my queries, I'm coming here for ideas/suggestions. My use case is for using Yeti to store my threat hunt queries and related information. I am a consultant so I have queries across many different technologies (OSQuery, Splunk, Carbon Black, Elasticsearch etc etc). I started out naming queries by T1047- etc etc but realised that i have multiple queries for the same technique. So:

1. Ill name with technique name and query type, like OSQuery for WMI event subscribers.
2. Utilise tags: attack_persistence, T1546, OSQuery.
3. Link to the attack entity and related information.

I'm still getting my head around the terminology and the linkages, so just checking if anyone does this in a way that makes sense already!

[tomchop]

How that's a great discussion topic! Thanks for bringing it up. If we reach consensus, I can totally see how this could go in a "recommended usage" guideline in the docs.

From a technical standpoint, it's important to realize that unicity is built from from Indicator name and type (not query_type). So if all you have are Indicators of type Query (which seems to be the case here), you need to disambiguate them like you're doing (maybe stating the obvious here but I thought I'd spell it out loud for the people in the back)

Name: Given that (hopefully) tags and target_systems provide enough metadata to be flexible when selecting rules, I think keeping the query name as human readable as possible is a good idea. Maybe to make it easier to visually scan I'd rename this to WMI event subscribers (OSQuery) but that's just splitting hairs.

Tags: what do you mean exactly by "attack_persistence" here? If you mean that this is linked to the Persistence attack-pattern object that you've created before, then this might be redundant with the graph link to that object. The tag OSQuery might also be redundant with the query_type (which you can also filter in the list by doing query_type=osquery)

Links: Yup, having attack-patterns linked to indicator objects is exactly how I have it set up as well. Be mindful of the direction of the link though, as it might have implications on how you're navigating the graph and retrieving indicators. e.g. in Timesketch, we start by selecting all entities fo type attack-pattern that are tagged e.g. triage, and then traverse the graph looking for indicators (instead of selecting indicators tagged attack_persistence)

[shannaniggans]

OK awesome!

I definitely think we should at least get a starting consensus and Ill add some recommendations in the documentation for consistency, and to help stop the analysis paralysis :)

Right now my main focus is adding in queries that i've written for threat hunting activities and its across multiple query languages. So:

Name	Query text	Relevant Tags	Query Type	Target Systems	Location	Diamond model	Description
Windows Management Instrumentation (Carbon Black Watchlist)	(process_name:wmic.exe cmdline:"process\ call\ create")	mitre-attack:execution T1047	Carbon Black Watchlist	Windows	Processes	Capability	Description text blah blah blah
Windows Management Instrumentation (OSQuery)	select p.pid,p.name, pp.pid as parentid,pp.name as parentname ,gp.pid as gpid,gp.name as gpname from processes p join processes pp on p.parent=pp.pid join processes gp on pp.parent=gp.pid where p.name like '%wmi%';	mitre-attack:execution T1047	OSQuery	Windows	Processes	Capability	Description text blah blah blah

Relevant Tags: Im using the tags that are related to the Mitre feed that I enabled, but also adding the technique as well.
Query type: As we have discussed, being able to add your own custom field here to expand out the types of queries, if thats the intent of the field.
Target Systems: For me I've been thinking Windows / Linux / MacOS as what I would be putting into this field? Maybe even going to the level of Windows Server: Domain Controller? VERIS listing might be overkill but perhaps a similar style? https://verisframework.org/enums.html#section-asset
Location: We also discussed this as a location like: file system, processes, event logs etc, the indicators as queries already in Yeti have the location the same in general as the query type. We could draft up a listing as suggestions and then have an other option for free text?

the rest is ok, but I think with a little more clarity around these for "Query" objects, I will be happy and ill also get going on building an importer from MISP query objects as well as csv.

[tomchop]

Sure thing, happy to provide a clarification. BTW, a lot of these are just something that we thought might be interesting at design-time, but I'm open to have them changed / removed / having other fields added.

Relevant tags: As opposed to just "regular" tags, these are supposed to be tags that will get propagated to whatever the indicator is supposed to match when a match happens (eg. a Timesketch event, an Observable in Yeti, etc.). Regular tags are more for inventory management of your queries (e.g. you might want to have an "opensearch" tag to be able to group your opensearch queries, but that's not relevant to the object that has matched the indicator). In this case I think the mitre-attack tags are a good use of "relevant tags".
Target systems: this was intended to be the system where the query is supposed to be run (e.g. Timesketch, where query_type is "OpenSearch".). This mostly so that automation that runs queries on these systems can easily filter them out (granted, we could also use tags for this).
Location: This is about where to find the objects the indicator is supposed to match - so in this case you'd have Windows Registry, Filesystem, etc. I have found that this is not super clear and I wonder exactly how useful it is.

I see there's a lot of confusion around Target systems and Location, maybe adding a dropdown with suggestions + free text (we already pushed this change for Target systems btw!) would be a first step.

@udgover @sebdraven what do you think? Should we keep Location in the indicators? Or is it just overkill and confusing? Should we just drop Target systems and merge that into query_type? (e.g. do we really care that this query that will anyways be used in Timesketch is Lucene / OpenSearch? Is it easier to just do query_type=timesketch?)