Introduction
The term “Automated SOC” sounds like an oxymoron, doesn’t it? For years, automation in the Security Operations Center has been limited to simple email notifications. However, the sheer volume of alerts, combined with a global shortage of skilled analysts, has forced a paradigm shift. We had a client, a logistics firm, that was collecting 50,000 events per second but was only able to investigate 20 incidents per day. The rest were ignored. To solve this, our team adopted an open-source orchestration engine (TheHive combined with MISP and Cortex) to automate the entire incident response lifecycle, from triage to containment. By leveraging open-source SOAR (Security Orchestration, Automation, and Response), we have built an autonomous response layer that handles Level-1 and Level-2 SOC tasks without human intervention, freeing up our analysts to pursue complex, sophisticated threats.
Deep Technical Analysis: Building the Orchestration Pipeline
Our architecture is simple but powerful. The pipeline flows: Log Ingestion (Wazuh) -> Alert Correlation (Elastalert) -> Case Creation (TheHive) -> Enrichment (MISP/Cortex) -> Response (Shuffle/Ansible) .
In a recent deployment, we focused on automating phishing response. When an employee reports a suspicious email, our Microsoft Graph API listener triggers TheHive to create a case. We then use Cortex to automatically analyze the email attachments using multiple AV engines (ClamAV, VirusTotal API) and extract URLs to check against URLhaus and MISP threat intelligence feeds.
The bottleneck, however, was response time. To solve this, we built custom Docker containers running Python scripts that integrate directly with our Cisco ISE (Identity Services Engine) and Azure AD. If an enrichment confirms a malicious file hash, our orchestration automatically invokes an Ansible playbook that queries the firewall for any internal IPs communicating with the malicious C2 server and immediately isolates those hosts using a cisco.ios_config module, and revokes the user’s OAuth tokens in Azure AD, logging them out of all active sessions.
This is what we call “automating the automated.” We used a state-machine logic (similar to Amazon Step Functions) to govern the response. If the confidence score is above 90%, the system auto-contains. If it is between 70-90%, it creates a high-priority case and pages the on-call analyst via PagerDuty with all context already attached.
Best Practices for Open-Source SOAR
Adopting open-source SOAR can be chaotic without governance. Here are the rules we abide by:
- Playbook Standardization: Use a standardized format like CACAO (Collaborative Automated Course of Action Operations) for your playbooks. This ensures your automation logic is not vendor-locked and can be exported to other SOAR tools if needed.
- API Rate Limits: Open-source tools often lack built-in API rate limiting. We implemented a Redis queue to manage the flow of API calls to our threat intelligence providers (like VirusTotal and AbuseIPDB) to avoid hitting daily caps.
- Human-in-the-Loop for Critical Assets: Never fully automate responses against Domain Controllers or ERP databases. Always require a manual approval step for actions that affect authentication systems or financial records.
- Log Everything: Since you are automating human actions, your audit trail must be bulletproof. Every automated command executed via Ansible or API must be logged with timestamps, usernames, and the triggering case ID for post-incident forensic reviews.
Conclusion
Open-source orchestration is the democratization of security automation. It allows SMBs and enterprises alike to build a 24/7 automated analyst that never sleeps. By implementing this pipeline, we reduced the Mean Time to Respond (MTTR) for our logistics client from 45 minutes to under 90 seconds for common threats like commodity malware and credential harvesting. The goal is not to replace human analysts, but to elevate them to become “threat hunters” rather than “ticket triagers.”