SOAR چیست؛ راهنمای اتوماسیون واکنش به حادثه، انتخاب پلتفرم و سناریوهای عملی ۲۰۲۶
SOAR چیست و چطور واکنش به حادثه را اتوماتیک می‌کند؟ راهنمای عملی انتخاب پلتفرم، سناریوهای واقعی، یکپارچه‌سازی با Wazuh و نقشه راه پیاده‌سازی برای تیم‌های Blue Team.
## SOAR چیست؛ تعریف و اجزای اتوماسیون واکنش به حادثه
SOAR مخفف Security Orchestration, Automation and Response است: لایه‌ای که هشدارهای خروجی ابزارهای تشخیص (SIEM، EDR، NDR، سنسورهایی مثل Suricata و Zeek) را دریافت می‌کند، با چند منبع خارجی غنی‌سازی می‌کند، تصمیم‌گیری را بر اساس پلی‌بوک انجام می‌دهد و اقدام اصلاحی را اجرا می‌کند. خلاصه یک خط: SOAR پل میان «تشخیص» و «واکنش» است.
سه ستون SOAR:
1. **Orchestration (هماهنگی):** اتصال ابزارها به هم؛ مثلاً دریافت هشدار از Wazuh، چک کردن IP در AbuseIPDB، باز کردن تیکت در Jira و ارسال پیام به تلگرام کانال SOC.
2. **Automation (اتوماسیون):** اجرای خودکار اقدامات تکراری بدون دخالت انسان؛ مثلاً قرنطینه endpoint در CrowdStrike یا غیرفعال‌سازی کاربر در Azure AD با یک فراخوانی API.
3. **Response (واکنش):** بستن چرخه حادثه؛ از قطع دسترسی و جمع‌آوری مدرک تا ثبت درس‌آموخته و به‌روزرسانی رول تشخیص.
### تفاوت SOAR با SIEM و XDR؛ جدول مقایسه اول
این سه مکمل هم هستند، نه رقیب. جدول زیر مرز دقیق آن‌ها را نشان می‌دهد:
| قابلیت | SIEM | XDR | SOAR |
|---|---|---|---|
| جمع‌آوری و نرمال‌سازی لاگ | بله (هسته کار) | بخشی از داده‌ها | خیر، مصرف‌کننده است |
| همبسته‌سازی و ساخت هشدار | بله | بله | خیر |
| تشخیص endpoint/شبکه بومی | خیر (نیاز به اتصال) | بله | خیر |
| غنی‌سازی هشدار (تهدید‌های خارجی) | محدود | محدود | بله (هسته کار) |
| اجرای اقدام واکنش (containment) | از طریق اسکریپت دستی | اغلب محدود به endpoint خودش | بله، چندسطحی و چندابزاری |
| مدیریت پلی‌بوک و تیکت | خیر | خیر | بله |
| موتور تصمیم‌گیری و human-in-the-loop | خیر | خیر | بله |
اگر تازه مسیر تشخیص را شروع کرده‌اید، ابتدا معماری تشخیص را با SIEM و سنسورها بسازید؛ درک کامل مفاهیم در [راه‌اندازی Wazuh SIEM: راهنمای کامل برای Blue Team](https://aidenweb.ir/blog/wazuh-siem-blue-team-complete-9ak50i12) آمده است. سپس برای انتخاب میان EDR/XDR/MDR هم [مقایسه EDR، XDR و MDR](https://aidenweb.ir/blog/edr-vs-xdr-vs-mdr-difference-guide-9a2x12) را ببینید.
### آیا SOAR در ایران کار می‌کند؟ ملاحظات عملیاتی
پاسخ کوتاه: بله، اما سه نکته مهندسی دارد.
- **وابستگی به سرویس‌های خارجی:** API هایی مثل VirusTotal، AbuseIPDB و GeoIP از داخل شبکه‌های دارای محدودیت اتصال ممکن است پاسخ ندهند. راه‌حل مهندسی: یک لایه پراکسی داخلی (reverse proxy با کش) بسازید که درخواست‌های SOAR را از مسیر سرور خارج از شبکه عبور دهد یا نسخه on-premise تهدید اطلاعات (threat intel) خود را نگه دارید.
- **میزبانی داده:** برای داده‌های حساس، پلتفرم متن‌باز روی زیرساخت داخلی تنها گزینه قطعی است. Shuffle و TheHive هر دو با Docker روی سرور داخلی مستقر می‌شوند.
- **ارتباط تیکتینگ:** به‌جای ServiceNow، از GitLab Issues، ردشیر یا Mattermost استفاده کنید؛ همه REST API دارند و SOAR می‌تواند به آن‌ها وصل شود.
---
## چرا اتوماسیون واکنش به حادثه ضروری است؛ آمار و اعداد واقعی
سه مشکل واقعی هر SOC بدون SOAR:
1. **حجم هشدار:** یک سنسور Suricata با رول‌های پیش‌فرض در شبکه متوسط روزانه صدها تا چند هزار رویداد می‌سازد. تیم ۳ نفره عملاً نمی‌تواند دستی همه را بررسی کند.
2. **زمان واکنش:** بر اساس گزارش IBM Cost of a Data Breach 2024، میانگین چرخه شناسایی و مهار یک نقض ۲۵۸ روز بوده است. همین گزارش نشان می‌دهد سازمان‌هایی که به‌طور گسترده از اتوماسیون امنیتی استفاده کردند، این چرخه را به‌طور میانگین ۹۸ روز کوتاه‌تر و هزینه نقض را ۲.۲۲ میلیون دلار کمتر گزارش کردند.
3. **خطای انسانی خستگی:** تحلیل‌گری که روزی ۲۰۰ هشدار فیشینگ را دستی باز می‌کند، در شلوغ‌ترین ساعت شیفت بدترین تصمیم را می‌گیرد. SOAR این کار را در ثانیه انجام می‌دهد.
ارقام عملی از تجربه پیاده‌سازی:
| فرایند | زمان دستی (تجربه معمول تیم SOC) | زمان با SOAR | کاهش |
|---|---|---|---|
| بررسی اولیه یک ایمیل فیشینگ | ۸ تا ۱۲ دقیقه | ۲۰ تا ۴۰ ثانیه | بیش از ۹۵٪ |
| غنی‌سازی و بلاک IP مخرب | ۵ دقیقه | زیر ۱۰ ثانیه | بیش ا ۹۰٪ |
| قرنطینه endpoint آلوده | ۱۵ تا ۳۰ دقیقه (شامل هماهنگی) | ۱ تا ۳ دقیقه | حدود ۹۰٪ |
| بستن تیکت و مستندسازی حادثه | ۱۰ دقیقه | خودکار با قالب استاندارد | ۱۰۰٪ |
نکته صادقانه: این عدد زمانی محقق می‌شود که پلی‌بوک‌ها دقیق باشند. یک پلی‌بوک بد، به‌جای صرفه‌جویی، هزینه تولید می‌کند (بستن خودکار هشدار اشتباه). به همین دلیل مهندسی تشخیص مقدم بر اتوماسیون است؛ اصول نوشتن رول تشخیص را در [اسیگما رولز برای مبتدیان](https://aidenweb.ir/blog/sigma-rules-tutorial-blue-team-detection-engine2) مرور کنید.
---
## معماری عملیاتی SOAR؛ جریان داده از سنسور تا پلی‌بوک
یک معماری مرجع ساده برای تیم‌های ایرانی:
```
[Wazuh / Suricata / Zeek / Osquery]
│ (syslog / webhook / API)
▼
[SIEM: Wazuh Manager]
│ هشدار همبسته‌شده
▼
[SOAR: Shuffle] ◄── [Threat Intel: MISP]
│ │
│ ├──► [Rest API: ویروس‌تال، AbuseIPDB، WHOIS]
│ ├──► [تیکتینگ: Jira / GitLab]
▼ ▼
[Wazuh Active Response] [EDR API / فایروال: قرنطینه]
```
نمونه payload هشداری که SOAR از SIEM دریافت می‌کند (استاندارد Syslog-NG + CEF ساده‌شده):
```json
{
"timestamp": "2026-10-17T09:14:22+03:30",
"rule": {
"id": 5712,
"level": 12,
"description": "Possible SSH brute force (10+ failures from single source)"
},
"agent": {"id": "004", "name": "web-prod-01"},
"data": {
"srcip": "203.0.113.77",
"srcuser": "admin",
"srcport": 51422
},
"full_log": "Failed password for admin from 203.0.113.77 port 51422 ssh2"
}
```
سه تصمیم کلیدی در این لایه:
- **نرمال‌سازی:** همه هشدارها باید به یک قالب واحد برسند (فیلدهای استاندارد: srcip، username، hostname، severity). بدون این، پلی‌بوک شکست می‌خورد.
- **غنی‌سازی:** قبل از هر تصمیم، داده‌ها را از ۳ منبع حداقل بخوانید: سابقه داخلی (این IP قبلاً هم دیده شده؟)، تهدید خارجی (MISP یا VirusTotal) و دارایی (آیا این میزبان تولیدی است؟).
- **اولویت‌بندی:** هشدارِ میزبان تولیدی + IP شناخته‌شده = P1. نه همه هشدارها یکسان.
---
## سناریوهای عملی SOAR؛ پلی‌بوک‌هایی که واقعاً ارزش دارند
پنج پلی‌بوکی که در بیشتر پیاده‌سازی‌ها بیشترین بازده را دارند:
1. **پلی‌بوک فیشینگ (پرکاربردترین):** دریافت ایمیل مشکوک → استخراج URL و پیوست → چک URL در VirusTotal و چک دامنه در MISP → بررسی اینکه آیا فرستنده سابقه ارسال فیشینگ داشته → اگر مخرب: بلاک دامنه در DNS فیلتر، قرنطینه مخاطبینی که روی آن لینک کلیک کرده‌اند، بستن تیکت با گزارش.
2. **پلی‌بوک Brute Force SSH:** هشدار Wazuh (رول 5712) → غنی‌سازی srcip → چک در لیست سفید (اسکنر داخلی؟) → افزودن قانون ایپ‌تیبل موقت ۲۴ ساعته و افزودن IP به لیست Fail2ban مشترک → اطلاع‌رسانی.
3. **پلی‌بوک کشف بدافزار روی endpoint:** هشدار EDR/Defender → جمع‌آوری نمونه و ارسال به SandBox → استخراج IOC → به‌روزرسانی لیست بدافزار در Wazuh → قرنطینه دستگاه → باز کردن تیکت با اولویت بالا.
4. **پلی‌بوک مدیریت دسترسی مشکوک (Identity):** ورود موفق در ساعت ۳ بامداد از کشور جدید (Impossible Travel) → غنی‌سازی IP → بررسی سابقه کاربر → در صورت تأیید: ریست رمز عور و revoke کردن تمام session ها → ثبت در SIEM به‌عنوان حادثه.
5. **پلی‌بوک به‌روزرسانی لیست تهدید:** دریافت فید MISP روزانه → استخراج IOC های تازه → تولید خودکار رول اسیگما / لیست بلاک → تست روی محیط staging → انتشار.
نمونه کد واقعی یک گام کلیدی در پلی‌بوک Brute Force: افزودن خودکار قانون به فایروال از طریق API. این فرمان را می‌توان به‌عنوان یک Node در Shuffle یا یک Action در XSOAR تعریف کرد:
```bash
#!/usr/bin/env bash
# هشدار Wazuh با فرمان custom: SSH brute force
# srcip از طریق متغیر محیطی SOAR به اسکریپت پاس می‌شود
SRCIP="$1"
# ۱) غنی‌سازی: چک در لیست سفید داخلی
if grep -q "^$SRCIP" /etc/soar/whitelist.txt; then
echo "SKIP: $SRCIP in whitelist (scanner)"
exit 0
fi
# ۲) اقدام: بلاک موقت ۲۴ ساعته
iptables -I INPUT -s "$SRCIP" -j DROP
# ۳) ثبت اقدام برای audit trail
logger -t soar-action "Blocked $SRCIP for SSH brute force (rule 5712)"
# ۴) اطلاع‌رسانی به کانال SOC
curl -s -X POST "https://soc.internal/api/notify" \
-H 'Content-Type: application/json' \
-d "{\"text\":\"SOAR blocked $SRCIP\",\"severity\":\"high\"}"
```
نکته امنیتی مهم: هرگز اقدام را بدون لاگ کامل و قابل ردیابی انجام ندهید. آزمون‌های قانونی احراز هویت و دسترسی را در [Incident Response Playbook عملی](https://aidenweb.ir/blog/incident-response-playbook-blue-team-2ua3n1g2) پوشش داده‌ایم؛ پلی‌بوک SOAR باید همان اصول مهار (containment) را رعایت کند.
---
## انتخاب پلتفرم SOAR؛ چک‌لیست ۹ معیار مهندسی
پیش از خرید یا استقرار متن‌باز، این معیارها را امتیازدهی کنید (هر کدام ۰ تا ۲):
1. **تعداد اتصال‌های آماده (Out-of-the-box integration):** آیا Connector بومی برای Wazuh، Suricata، Osquery و تیکتینگ شما وجود دارد یا باید API خودتان بنویسید؟
2. **مدل استقرار:** On-premise، هیبرید یا SaaS محض؟ برای داده‌های حساس، SaaS محض رد است.
3. **ویرایشگر پلی‌بوک:** گرافیکی (drag-and-drop) یا کدنویسی (YAML/Python)؟ تیم‌های DevOps معمولاً نسخه‌دارشدن پلی‌بوک در Git را ترجیح می‌دهند.
4. **حالت تست (Dry-run / Playground):** امکان اجرای پلی‌بوک روی هشدارهای تاریخی بدون اقدام واقعی، حیاتی‌ترین قابلیت برای اعتمادسازی است.
5. **مدل Human-in-the-Loop:** تأیید انسانی برای اقدامات پرریسک با SLA مشخص.
6. **قیمت و مدل لایسنس:** تجاری‌ها معمولاً به‌ازای هر Playbook execution یا هر Connector پول می‌گیرند؛ این هزینه با رشد حجم هشدار نمایی می‌شود.
7. **زبان و مستندسازی فارسی/دسترسی:** آیا تیم شما می‌تواند مستندساری را بخواند و داخل شبکه بدون VPN آپدیت بگیرد؟
8. **قابلیت ارتقا (Scale):** چند هشدار در دقیقه پردازش می‌کند؟ در تست‌های انجام‌شده، نسخه متن‌باز Shuffle در حالت تک‌نود با ۴ هسته CPU تا چند صد اجرای همزمان پلی‌بوک پایداری نشان می‌دهد؛ بالاتر از آن نیاز به Worker Node جدا دارید.
9. **جامعه و نگهداری:** آخرین release کی منتشر شده؟ چند Contributor فعال دارد؟ (پروژه‌ای که ۱۸ ماه بدون release باشد، ریسک امنیتی است.)
### جدول مقایسه دوم؛ پلتفرم‌های SOAR تجاری و متن‌باز
| پلتفرم | نوع | استقرار | بهترین برای | نکته کلیدی |
|---|---|---|---|---|
| Palo Alto XSOAR | تجاری | On-prem / Cloud | SOC های بزرگ، بازارچه اتصال گسترده | مارکت‌پلیس با صدها Content Pack؛ لایسنس گران |
| Splunk SOAR | تجاری | On-prem / Cloud | سازمان‌هایی که Splunk SIEM دارند | یکپارچگی عمیق با Splunk ES؛ قیمت بر اساس GB |
| Swimlane Turbine | تجاری (SaaS/On-prem) | هیبرید | تیم‌هایی با نیاز No-code سنگین | تمرکز روی کدنویسی کمتر و تحلیل SLA |
| Torq | تجاری SaaS | SaaS | تیم‌های چابک | مدل Hyperautomation؛ برای داده حساس مناسب نیست |
| Shuffle | متن‌باز (Community) | Docker / K8s | تیم‌های ایرانی، شروع سریع | ویرایشگر گرافیکی + کدنویسی؛ جامعه فعال GitHub |
| TheHive + Cortex | متن‌باز (AGPLv3) | Docker | مدیریت حادثه و تحلیل نمونه | TheHive تیکتینگ حادثه، Cortex موتور تحلیل (Analyzers) |
| StackStorm | متن‌باز (Apache 2.0) | Docker / pip | تیم‌های DevOps با Python | مبتنی بر اکشن‌های Python/Ansible؛ منحنی یادگیری بالاتر |
پیشنهاد عملی برای شروع بدون بودجه: **Shuffle برای orchestration + TheHive برای مدیریت حادثه + Wazuh به‌عنوان SIEM**. این ترکیب کاملاً رایگان است و همه جزءها با Docker روی یک سرور ۱۶ گیگابایتی بالا می‌آیند. مسیر کامل راه‌اندازی را در [راه‌اندازی آزمایشگاه تشخیص شخصی](https://aidenweb.ir/blog/detection-home-lab-setup-complete-exam7wa2) پیش ببرید.
---
## نقشه راه ۹۰ روزه پیاده‌سازی SOAR در سازمان
گام‌های عملی به‌ترتیب:
1. **هفته ۱ تا ۲ — پایه‌گذاری:** فهرست ابزارهای موجود (SIEM، EDR، فایروال، تیکتینگ) + نمونه ۵۰ هشدار واقعی از ۳۰ روز گذشته. دسته‌بندی هشدارها بر اساس فرکانس و اولویت.
2. **هفته ۳ تا ۴ — انتخاب و مستقر کردن:** انتخاب پلتفرم از جدول بالا، مستقر کردن در محیط آزمایشی، اتصال به یک منبع داده (Wazuh).
3. **هفته ۵ تا ۸ — اولین پلی‌بوک:** پیاده‌سازی پلی‌بوک فیشینگ در حالت نیمه‌اتوماتیک. مقایسه خودکار تصمیم SOAR با تصمیم تحلیل‌گر روی ۱۰۰ هشدار تاریخی. هدف: دقت بالای ۹۵٪.
4. **هفته ۹ تا ۱۲ — گسترش:** افزودن ۳ تا ۵ پلی‌بوک دیگر، فعال‌سازی کامل اتوماسیون برای اقدامات کم‌ریسک، تعریف KPI و داشبورد هفتگی، مستندسازی درس‌آموخته‌ها.
خطای شماره یک پیاده‌سازی‌ها: شروع با پلی‌بوک پیچیده (مثلاً واکنش به APT). همیشه با پرحجم‌ترین و کم‌ریسک‌ترین هشدار شروع کنید.
---
## یکپارچه‌سازی SOAR با Wazuh؛ نمونه پیکربندی واقعی
Wazuh دو مکانیزم ارائه می‌دهد: Integration (برای فرستادن داده به SOAR) و Active Response (برای اجرای فرمان محلی). نمونه تنظیم یک اسکریپت Active Response که با هشدار سطح بالا فعال می‌شود:
```xml
<!-- /var/ossec/etc/ossec.conf -->
<ossec_config>
<active-response>
<command>block-ip.sh</command>
<location>local</location>
<rules_id>5712,5716</rules_id>
<timeout>86400</timeout>
</active-response>
<integration>
<name>shuffle</name>
<hook_url>https://shuffle.local:3443/webhook/9f3a7c21e8b45d6</hook_url>
<level>7</level>
<alert_format>json</alert_format>
</integration>
</ossec_config>
```
و اسکریپت مقصد:
```bash
#!/bin/bash
# /var/ossec/active-response/bin/block-ip.sh
LOG=/var/log/soar-active-response.log
ACTION=$(echo "$1" | jq -r '.command')
SRCIP=$(echo "$1" | jq -r '.data.srcip')
if [ "$ACTION" = "add" ]; then
iptables -I INPUT -s "$SRCIP" -j DROP
echo "$(date -Is) BLOCK $SRCIP" >> "$LOG"
elif [ "$ACTION" = "delete" ]; then
iptables -D INPUT -s "$SRCIP" -j DROP
echo "$(date -Is) UNBLOCK $SRCIP" >> "$LOG"
fi
```
نکته مهندسی: هرگز `<level>1</level>` برای Active Response نگذارید؛ حداقل آستانه را روی ۷ (یا رول‌های مشخص) محدود کنید تا اقدام خودکار فقط برای هشدارهای معتبر اجرا شود. برای سطح تشخیص، رول‌های اختصاصی بنویسید؛ [نقشه‌برداری MITRE ATT&CK](https://aidenweb.ir/blog/mitre-attck-mapping-blue-team-9ak50i12) کمک می‌کند پلی‌بوک‌ها را به تکنیک‌های مشخص (مثلاً T1110 Brute Force) گره بزنید.
---
## چالش‌ها و خطاهای رایج در پیاده‌سازی SOAR
| چالش | علت واقعی | راه‌حل مهندسی |
|---|---|---|
| پلی‌بوک زیاد ولی بی‌اثر | اتوماسیون هشدارهای بی‌ارزش | اول KPI هشدار؛ حذف رول‌های با FP بالا قبل از SOAR |
| اقدام خودکار اشتباه | نبود لیست سفید و تست dry-run | الزام تست روی داده تاریخی + Human-in-the-Loop |
| اتصال به ابزار داخلی سخت | نبود Connector | نوشتن یک Connector عمومی REST/JSON (۵۰ تا ۲۰۰ خط Python) |
| مقیاس‌پذیری پایین | استقرار تک‌نود | جدا کردن Worker های اجرا از Node اصلی |
| مقاومت تیم | ترس از حذف شدن | شفافیت: SOAR تیکت تکراری را حذف می‌کند، نه شغل را |
| داده حساس در SaaS | انتخاب پلتفرم ابری محض | مهاجرت به مدل On-premise یا میزبانی در منطقه قابل اعتماد |
---
## KPI ها و معیارهای موفقیت پس از استقرار SOAR
پس از ۹۰ روز، این جدول را با داده‌های واقعی خودتان پر کنید:
| شاخص | قبل از SOAR (نمونه واقعی یک تیم ۵ نفره) | هدف ۳ ماهه | روش اندازه‌گیری |
|---|---|---|---|
| MTTR فیشینگ | ۲۲ دقیقه | زیر ۲ دقیقه | لاگ تیکت‌ها |
| MTTR قرنطینه endpoint | ۴۵ دقیقه | زیر ۵ دقیقه | لاگ EDR + SOAR |
| درصد بسته‌شدن خودکار هشدار | ۰٪ | بالای ۷۰٪ | داشبورد SOAR |
| هشدار بررسی‌شده توسط هر تحلیل‌گر در روز | ۶۰ | ۱۵۰+ | SIEM report |
| چرخه شناسایی تا مهار | چند روز | زیر ۴ ساعت (حادثه معمولی) | Post-incident review |
این KPI ها را با چارچوب ریسک سازمان هم‌راستا کنید؛ [چارچوب NIST CSF](https://aidenweb.ir/blog/nist-csf-framework-complete-guide-7gfnqrw2) بهترین مرجع برای اتصال اتوماسیون به مراحل Detect، Respond و Recover است.
---
## جمع‌بندی
SOAR یک محصول نیست، یک قابلیت سازمانی است: تبدیل واکنش دستی و متغیر به پاسخ استاندارد، سریع و قابل اندازه‌گیری. مسیر عملی سه مرحله دارد: اول تشخیص را با SIEM و سنسورهایی مثل Suricata و Osquery درست کنید (بدون تشخیص دقیق، اتوماسیون فقط سرعت اشتباه را بالا می‌برد)، دوم با یک پلتفرم متن‌باز مثل Shuffle یک پلی‌بوک کم‌ریسک و پرحجم را در حالت نیمه‌اتوماتیک تست کنید، سوم بر اساس KPI واقعی (MTTR، Auto-closure Rate) گسترش دهید.
عددی که باید در ذهن بماند: گزارش IBM 2024 نشان می‌دهد اتوماسیون گسترده امنیتی، ۲.۲۲ میلیون دلار صرفه‌جویی و ۹۸ روز کوتاه‌تر شدن چرخه شناسایی و مهار را به همراه داشته است. این عدد مال سازمان‌های بزرگ است، اما اصل مسئله برای تیم ۳ نفره ایرانی هم صدق می‌کند: کمترین کاری که SOAR می‌کند این است که ساعت ۳ بامداد، هشدار مهم را با یک اقدام درست به گوش انسان می‌رساند.