How do you manage user roles and permissions at scale in ThreatConnect?

Having just come through a large-scale, multi-team deployment of ThreatConnect, I can tell you that managing user roles and permissions is one of those areas that starts simple but can become a genuine administrative labyrinth as you grow. We onboarded over 200 users across Security Operations, Threat Intelligence, and Incident Response teams, and our initial "just give everyone Analyst" approach predictably fell apart within weeks. The journey from there to a scalable model was... educational.

The core challenge, in my experience, is that ThreatConnect's out-of-the-box roles are a good starting point, but they are inherently broad. The "Administrator," "Analyst," and "Read Only" paradigm doesn't capture the nuanced needs of a modern security organization. For instance, you might need a vendor partner who can create and tag Indicators in a specific shared workspace, but absolutely cannot see your internal Incident work. Or you might have senior analysts who need to approve Indicators for publication but shouldn't have full system admin rights.

Here’s how we structured our approach to achieve scale and maintain sanity:

* **Embrace Custom Roles as Your Primary Tool:** This is non-negotiable. We stopped using the built-in roles for anyone beyond a handful of true system admins. We created a matrix of *capabilities* (e.g., "Create Incidents in Team-A Workspace," "Approve Tags in Intelligence Source X," "Run Playbooks in the Sandbox") and then bundled them into custom roles.
* **Map Roles to Organizational Structure, Not Individuals:** We defined roles like `TI-Member-Contribute`, `IR-Lead-Manage`, and `Vendor-Partner-ReadOnly`. Each role was tied to a specific set of groups and workspaces. New users get a role based on their team function, not a bespoke permissions review.
* **The Critical Dance of Groups, Workspaces, and User Associations:** This is the engine. Permissions are granted at the intersection of these three elements. We learned to be ruthlessly organized:
* **Groups** mirror our organizational units (e.g., "ThreatIntel," "EMEA-SOC," "Vendor-Acme").
* **Workspaces** are scoped to initiatives or data types (e.g., "Campaign-Tracking," "Malware-Analysis-Reports," "External-Feeds").
* A user's **Role** (custom, of course) determines what they can *do* within the Groups and Workspaces to which they are *associated*.
* **Implement a Single Source of Truth:** We quickly realized that managing this matrix inside ThreatConnect's UI for 200+ people was a path to errors. We maintain a simple spreadsheet that maps our custom role names to the precise permissions (at the Group/Workspace level) and use that as our change control document. Any provisioning or de-provisioning is done by referencing this document.
* **Regular Audits are Not Optional:** Quarterly, we run the "Members" report and reconcile it against our HR list. We also spot-check critical custom roles to ensure no permission drift has occurred.

The biggest "aha" moment was understanding that a user can have multiple roles across different groups. A team lead might have the `IR-Lead-Manage` role in their primary Incident Response group, but only the `TI-Member-Contribute` role in the broader Threat Intelligence group. This flexibility is powerful, but without documentation, it becomes impossible to track.

My strongest piece of advice: start with the principle of least privilege *from day one*, even if you only have ten users. Building the habit and the structure early is infinitely easier than trying to retrofit granular permissions onto a messy, over-permissioned deployment later. The initial overhead feels heavy, but it pays for itself the first time you need to onboard a new partner team or isolate access during a sensitive investigation.