I’m trying to build a picture of what a mature Tines deployment looks like in a SOC context. What tools are typically connected, what workflows are most commonly automated, and how does Tines fit into the broader stack alongside things like a SIEM, EDR, and ticketing system? If anyone has a rough architecture they’re willing to share, that would be incredibly useful.
That’s a great question, and it’s a bit hard to answer with one single diagram since it really depends on team size and maturity, but there’s a pretty recognizable pattern that shows up across most mature Tines deployments in a SOC.
Tines usually sits in the middle of the stack as the orchestration layer, not really replacing any one tool but gluing the SIEM, EDR, identity provider, threat intel sources, and ticketing system together.
The mental model that seems to hold up well is: SIEM and EDR generate the signal, Tines ingests it, enriches it, decides what matters, and then either takes action directly (isolating a host, disabling a user) or hands off to a human via a ticket or a Slack prompt. So it’s less “Tines replaces your SOC tools” and more “Tines is the connective tissue that used to be a person copy-pasting between six browser tabs.” 
In terms of what typically gets automated first, it’s almost always phishing triage and alert enrichment, since those are high volume and fairly mechanical. Tines has a good writeup on the phishing pattern specifically, using Proofpoint or Defender for Office 365 as the trigger, then extracting URLs and attachments, checking them against threat intel feeds, and scoring the message before a human ever sees it.
Once phishing and basic alert enrichment are solid, teams tend to move into containment style automation, things like automatically isolating an endpoint via EDR when a managed threat hunting service flags a device, while simultaneously opening a Jira ticket and tagging the relevant SIEM logs for review. That “act immediately, document in parallel” pattern comes up constantly once a SOC matures past pure notification-based automation.
There’s a broader guide that maps this progression out pretty well, covering monitoring, automation, and even incident preparation (predefining what logs and forensic artifacts get pulled the moment something fires, so nobody’s scrambling for ephemeral cloud logs after the fact).
On the tool side, a fairly typical connected stack looks something like:
- SIEM (Splunk, Sentinel, Elastic, etc.) as the alert source
- EDR (CrowdStrike, SentinelOne, Defender) for enrichment and containment actions
- Identity provider (Okta, Azure AD) for user context and account actions
- Threat intel sources (VirusTotal, Recorded Future, AbuseIPDB, URLScan) for enrichment
- Ticketing (Jira, ServiceNow) for case tracking
- Slack or Teams for human in the loop decisions and notifications
The security solutions page has a decent framing of this as a lifecycle, enrich, triage, respond, that maps closely to how most teams actually build it out in Tines over time rather than all at once.
If you want to see actual reference architectures rather than just descriptions, the Tines library has categories specifically for this. The “Endpoint detection and response,” “Incidents and alerts,” and “Phishing attack response” categories are the best starting points since they contain real importable stories rather than blog level descriptions.
One thing worth keeping in mind:
Most mature deployments didn’t start mature.
They usually started with one painful, high volume manual process (phishing being the most common first project), then expanded outward as trust in the automation built up.
So if you’re mapping this out for your own team, it’s probably more useful to think of it as a roadmap than a single architecture to build on day one.