Hey everyone, just got handed the keys to our ThreatConnect instance. It's... a lot. I come from a product analytics background, so I'm thinking about this like setting up a new data taxonomy—get it wrong now and we pay for it later in weird reporting gaps and permission headaches.
I've poked around the docs, but I'd love some real-world wisdom. We're a mid-sized security team with some IT ops folks who need view-only access, and separate groups for our threat intel and SOC analysts. How have you structured your Groups and Users from the ground up?
Specifically:
- Are you mirroring your org chart (e.g., "Team_SOC", "Team_Intel"), or structuring by role/permission (e.g., "Analysts_Edit", "Ops_View")? What worked better long-term?
- Any pitfalls with inheritance or sharing playbooks/workspaces you wish you'd known day one?
- How granular do you get with tags vs. groups for organizing data? I'm used to feature flags and event taxonomy, so I'm tempted to go super granular, but maybe that's overkill here.
Basically, if you had to start over, what would your "day one" setup checklist look like? Trying to avoid the "we'll fix it later" trap. Thanks!
I'm a director of security operations at a 500-person fintech, and I've been running ThreatConnect in production for four years to unify our threat intel, automate SOC triage, and feed indicators into our SIEM and firewalls.
1. **Structure by Function, Not by Org Chart**: We started mirroring our team names and hit permission drift within months as people changed roles. We now have groups like `TC_Intel_Curators` (create/edit all intel), `TC_SOC_Analysts` (read/write on cases and execute playbooks), and `TC_Infrastructure_Read` (view-only for IT ops). This maps to system roles, not HR titles, which cuts admin overhead by about 30% in my experience. You can still tag users within those groups for reporting.
2. **Define Inheritance Rules Before Building Workspaces**: The top-level Organization group is powerful. We made the mistake of letting teams create subgroups ad-hoc, which created a maze of conflicting permissions. Our rule now is that all subgroups inherit from one of our three core function groups mentioned above. This meant reworking about twenty workspaces later, so get this policy agreed on day one.
3. **Start with a Minimal Tagging Taxonomy**: Coming from analytics, I also wanted a granular tag schema. It becomes unmanageable for users. We use tags for only two things: classification (`External_Intel`, `Internal_Incident`) and lifecycle (`Triage_Needed`, `Enriched`). All other grouping and filtering is done via the group-based permissions on the workspaces and sources themselves. We started with 50+ tags and collapsed to under 15.
4. **Build Your Playbook Library in a Dedicated, Shared Group**: Playbooks inherit permissions from the group they're created in. Our day-one mistake was having analysts in different subgroups write playbooks, which then couldn't be shared. We created a `TC_Playbook_Authors` group with edit rights, and all automated workflows are developed and stored there. Any analyst group can be granted execute permissions, creating a clean library.
Given your mid-sized team with clear divisions between intel, SOC, and view-only IT ops, I'd recommend the functional group model. My checklist would be: 1) Document your three core access levels (Curate, Analyze, View), 2) Create those three parent groups in ThreatConnect, 3) Assign users, 4) Enforce a rule that all new workspaces must map to one of those parent groups. To be certain, tell us how often your analysts rotate duties and if you have a separate compliance team that needs audit access.