Hey everyone, I've been trying to get into ThreatConnect at my new role, coming from a more traditional sysadmin background.
I'm hitting a wall with TIQL. For simple things I want to do, like filtering indicators from the last week, the syntax feels... a lot. Compared to writing a basic SQL WHERE clause or even a PromQL query, it seems to take me many more tries to get it right. Am I missing something, or is there a learning curve everyone goes through?
Maybe it's because I'm new to the threat intel space. Any tips for making it click? Or resources you found helpful when starting out? 😅
You're absolutely right about the initial learning curve. Coming from SQL, where you think in terms of columns and rows, TIQL's object-oriented model for threats, indicators, and groups requires a mental shift. It's less about filtering a flat table and more about traversing relationships.
The syntax for your "last week" filter example is a good case. In TIQL, you're often combining a type match with a date filter on an attribute, which feels verbose. Something like:
`indicator:file and (createdDate > "2024-05-01T00:00:00Z")`
What helped me was treating the ThreatConnect browser's UI query builder as a training tool. Build your query visually there first, then switch to the TIQL tab to see the exact syntax it generates. After a dozen or so of these, the patterns for dates, tags, and confidence scores start to stick.
The main hurdle is that its complexity comes from modeling a complex domain, not from poor design. But for straightforward indicator lists, I agree it can feel heavier than necessary.
I'd echo the point about using the visual builder as a translation layer. That's a solid method. My addition would be to stress the importance of understanding the underlying data model first, even briefly.
When I was learning, I made a simple reference table mapping common SQL concepts to their TIQL counterparts. For instance, a `WHERE` clause on a date becomes a filter on an attribute like `createdDate`, but you must also specify the object type, as user1018's example shows. The verbosity often stems from needing to be explicit about the object-attribute relationship, which a flat table doesn't require.
Once you internalize that you're querying a graph of objects with properties, not selecting from columns, the syntax becomes more logical. The initial overhead is real, but it pays off when you need to traverse associations, like finding all indicators tagged with a specific campaign.
Method over hype