Building a Security Operations Center (SOC): Tier 1/2/3 Model
How to build or evaluate a SOC — in-house vs MSSP tradeoffs, the analyst tier model, SOAR automation, and the metrics that define SOC effectiveness.
Building a Security Operations Center (SOC): Tier 1/2/3 Model
A Security Operations Center (SOC) is the team and technology platform responsible for continuously monitoring, detecting, investigating, and responding to security threats. For companies with meaningful security obligations — regulated data, enterprise customers, or public market exposure — a SOC is not optional. The question is not whether to have one, but what model fits your organization's size, budget, and risk profile.
SOC Models: In-House vs. MSSP vs. Hybrid
In-House SOC:
The organization builds and operates its own SOC with dedicated security analysts, its own SIEM, and its own incident response capability.
Advantages:
- Deep knowledge of the business context — analysts know what "normal" looks like
- Faster escalation and decision-making
- No data sharing with third parties
- Fully customized detection for your specific environment
Disadvantages:
- Expensive: a 24/7 in-house SOC requires 8-12 analysts minimum (coverage, redundancy, attrition)
- Security talent is scarce and expensive
- The team depth needed for Tier 3 threat hunting and Tier 2 incident response is difficult to maintain at smaller organizations
- SIEM licensing, infrastructure, and tooling are additional costs
Best for: Large enterprises with mature security programs (500+ employees, regulated industries, security-critical products).
MSSP (Managed Security Service Provider):
A third-party provider operates the SOC on your behalf. Common vendors: Arctic Wolf, Expel, Orca Security MDR, Rapid7 MDR.
Advantages:
- 24/7 coverage without building an 8-person internal team
- Mature detection logic and threat intelligence built over years across hundreds of customers
- Faster time-to-value than building in-house
- Scales with your data volume
Disadvantages:
- Less business context — the MSSP analyst does not know that
billing-batch-jobrunning at 3 AM is expected - Data sovereignty concerns — your logs go to the MSSP's infrastructure
- Dependence on the MSSP's alert quality and response procedures
- Escalation latency can be significant for complex incidents
Best for: Mid-market companies (50-500 employees) that need 24/7 coverage but cannot justify an in-house team.
Hybrid SOC:
Internal security team handles Tier 2/3 (investigation, threat hunting, incident response) while an MSSP handles Tier 1 (alert triage, initial filtering). The MSSP escalates confirmed incidents to the internal team.
Best for: Companies with a small internal security team that needs 24/7 alert monitoring coverage without the cost of a full in-house SOC.
The Analyst Tier Model
SOC analysts are organized into tiers based on capability and focus:
Tier 1: Alert Triage
Responsibilities:
- Monitor the SIEM alert queue in real time
- Initial triage: is this a true positive, false positive, or needs more investigation?
- Gather initial enrichment (IP reputation, asset ownership, user context)
- Escalate confirmed or suspected incidents to Tier 2
- Handle routine security tasks (phishing reports, access requests)
Skills required:
- SIEM query basics (Splunk SPL, KQL)
- Understanding of common attack patterns
- Familiarity with the organization's infrastructure
Tools:
- SIEM alert dashboard
- Threat intelligence platforms (VirusTotal, AlienVault OTX)
- Asset and identity management (CMDB, directory)
- Ticketing system
Target throughput: A Tier 1 analyst should handle 25-50 alerts per shift. If alert volume exceeds this, either reduce noise (tuning) or add capacity.
Tier 2: Incident Investigation
Responsibilities:
- Investigate escalated incidents
- Determine scope and impact (what systems, what data, what users affected?)
- Coordinate containment and eradication actions
- Communicate with affected teams and stakeholders
- Write incident reports
Skills required:
- Deep understanding of attack frameworks (MITRE ATT&CK)
- Log analysis across multiple source types
- Forensic fundamentals (memory, disk, network forensics)
- Strong communication skills
Tools:
- EDR (threat hunting interface)
- Forensics tools (Volatility, Autopsy)
- Cloud investigation tools (AWS CloudTrail Insights, GCP SCC)
- Collaboration and ticketing
Typical workload: A Tier 2 analyst handles 2-5 incidents per day depending on complexity.
Tier 3: Threat Hunting and Engineering
Responsibilities:
- Proactive threat hunting — searching for threats that evaded detection
- Detection engineering — writing and improving SIEM and EDR detection rules
- Purple teaming — working with red team to validate and improve detections
- Tooling development — building automation, integrations, and enrichment pipelines
- Mentoring Tier 1 and Tier 2 analysts
Skills required:
- Advanced adversary TTP knowledge
- Scripting (Python, PowerShell)
- SIEM query expertise
- Red team perspective (understanding attacker methodology)
Output: Threat hunting reports, new detection rules, detection improvement tickets, training content.
SOAR: Security Orchestration, Automation, and Response
SOAR platforms (Palo Alto XSOAR, Splunk SOAR, Torq, Tines) automate repetitive Tier 1 workflows, enabling analysts to focus on investigation rather than mechanical enrichment tasks.
High-value automation playbooks:
Phishing email triage:
Trigger: Phishing report submitted to mailbox
Automated steps:
1. Extract URLs and attachments from reported email
2. Submit URLs to VirusTotal, URLScan.io
3. Check sender domain age and SPF/DKIM/DMARC status
4. Query SIEM for other employees who received the same email
5. If VT score > 3/72 OR sender domain < 30 days:
→ Auto-block sender domain in email gateway
→ Quarantine email in all mailboxes
→ Alert Tier 2 analyst with enriched summary
6. If benign indicators:
→ Close ticket as false positive
→ Send training feedback to reporting user
Failed login alert:
Trigger: 10+ failed logins for same account in 5 minutes
Automated steps:
1. Look up account in directory — is it human or service account?
2. Check if source IP is known bad (threat intel lookup)
3. Check if source IP matches expected user location
4. Check if there was a successful login following the failures
If source IP is known bad OR successful login followed failures:
→ Lock account
→ Alert Tier 1 with enriched context
→ Create P2 incident ticket
Otherwise:
→ Alert Tier 1, lower priority
Tines (low-code SOAR) automation example:
Story: "Enrich and triage IP-based alert"
Actions:
- name: Get alert details from SIEM
service: siem_api
- name: Check IP reputation
service: abuseipdb
options:
ip: "{{ .alert.source_ip }}"
- name: Lookup IP geolocation
service: ipinfo
- name: Check against internal allowlist
service: internal_api
- name: Route based on risk score
condition:
if: "{{ .abuseipdb.score > 50 }}"
then: create_high_priority_ticket
else: create_low_priority_ticket
SOC Metrics
Track these metrics to measure SOC effectiveness:
| Metric | Definition | Target |
|---|---|---|
| MTTA (Mean Time to Acknowledge) | Alert → analyst begins investigation | < 15 min |
| MTTC (Mean Time to Contain) | Alert → containment action taken | < 1 hr (P1) |
| False Positive Rate | Alerts that are not real threats | < 30% per rule |
| Alert Volume Trend | Month-over-month alert count | Decreasing or stable |
| Escalation Rate | Tier 1 alerts escalated to Tier 2 | 5-15% |
| Detection Coverage | % ATT&CK techniques with detection | Increase quarterly |
| Threat Hunting Leads per Month | Proactive threat hunt findings | 2-5/month |
Quality over quantity: A SOC that generates 500 alerts per day but only 10 are real is less effective than one that generates 100 alerts per day with 40 being real. Invest in noise reduction and detection quality over coverage breadth.
A SOC is an organizational capability, not a technology deployment. The tools matter less than the people, processes, and continuously improving detection logic that make the SOC effective against the actual threats targeting your organization.