While onboarding new analysts onto any threat intelligence platform, the core challenge is translating abstract UI clicks into concrete mental models and reproducible workflows. Based on benchmarking several training approaches for complex platforms like ThreatConnect, I've found a structured, scenario-based method coupled with direct platform configuration yields the fastest time-to-competency.
I recommend a three-phase approach, moving from guided observation to independent operation:
**Phase 1: Foundational Context & Observation**
* Before granting platform access, run a 1-2 hour session covering:
* Core data models (Indicators, Groups, Adversaries, etc.) as they map to real-world entities.
* The directed acyclic graph (DAG) relationship model—this is the conceptual backbone.
* Key UI sections (Workspaces, Analytics, Campaigns) and their specific purposes.
* Follow this with a live, narrated walkthrough of a canonical workflow. Example: "We receive a malicious IP. Here is the process from creating the Indicator, to enriching it via a TI source, to linking it to an existing Campaign, and finally publishing a Report."
**Phase 2: Guided, Repetitive Practice in a Sandbox**
This is the critical phase. Avoid theoretical exercises. Instead, create a dedicated "Training" Org or Community for safe experimentation. Provide analysts with a structured playbook in a markdown or checklist format. A simplified example workflow for them to execute:
```yaml
# Training Exercise: Indicator Enrichment & Analysis
Objective: Enrich a given IOC and assess its context.
Steps:
1. In your Training Workspace, create a new Host Indicator for `malicious-sample[.]com`.
2. Run enrichment using the built-in VirusTotal connector.
- Action: Click Indicator -> 'Enrich' -> Select 'VirusTotal'
3. Create a new Group of type 'Campaign' named 'Training-Campaign-2024'.
4. Establish a relationship: Link the enriched Indicator to the new Campaign using the 'Targets' relationship.
5. Generate a simple Report using the 'Simple Report' template, summarizing the indicator and its newly linked campaign.
```
Repeat this pattern for 5-7 core workflows (e.g., creating a Playbook, using a Tag for triage, building an Analytic). The goal is muscle memory.
**Phase 3: Simulated Operational Drills**
Finally, conduct time-boxed drills using sanitized real-world data. Present a simulated email with IOCs and a vague threat description. Task the analyst with documenting their process from ingestion to reporting within the platform. Review their work not just on completion, but on their adherence to data model conventions and relationship graph clarity.
Key tools to support this: Leverage ThreatConnect's built-in video tutorials for foundational knowledge, but immediately supplement with your organization's specific use cases. The platform's flexibility is a double-edged sword; without concrete, repeated practice in your own context, analysts will struggle to internalize the workflow logic.
benchmark or bust
benchmark or bust
I'm David Chen, a data engineering lead at a mid-sized fintech, managing a mixed stack of BigQuery and Snowflake for our analytics workloads, with several teams of analysts running queries in both platforms daily.
* **Analyst skill floor vs. flexibility**: BigQuery wins for getting new analysts from zero to basic queries fastest because of its serverless nature, lack of DWH sizing concepts, and standard SQL. Snowflake requires teaching warehouse sizing (XS-4X-L) and suspension policies. However, Snowflake's more granular RBAC and resource monitoring (per-user credit burn) gives you better cost control for more advanced, self-service use cases.
* **Initial cost of training & mistakes**: For pure training, BigQuery's on-demand pricing is predictable for unpredictable new-user query patterns; a novice's poorly-joined 10TB table scan costs ~$50, which stings but won't break the bank. In Snowflake, a new analyst left running a medium warehouse on a loop can burn $300+ in credits in a day if you don't set up budget alerts.
* **Development sandbox setup**: Creating a disposable, full-fidelity training dataset is easier in Snowflake via zero-copy cloning of production databases into a separate training account. In BigQuery, you'll be copying terabytes (incurring storage costs) or building subsetted views, which often miss real performance characteristics.
* **Platform-specific SQL gotchas**: Training must cover specific syntax quirks. For BigQuery, it's DATE functions and UNNEST for arrays. For Snowflake, it's understanding explicit CTAS for temporary tables and the different behavior of AUTOMATIC clustering. Missing these leads to immediate frustration and inefficient queries.
Given your focus on speed-to-competency for threat intel analysis, I'd start them on BigQuery for its lower initial concept load. If your primary need shifts to enforcing strict data governance and cost accountability across many advanced users, that's when I'd lean toward Snowflake. To make a cleaner call, tell me your expected monthly query volume in TB and whether your analysts will need to create and manage their own data models.
data is the product