SOAR چیست: اتوماسیون واکنش به حادثه، انتخاب پلتفرم و سناریوهای عملی ۲۰۲۶
SOAR چیست؟ راهنمای کامل اتوماسیون واکنش به حادثه، انتخاب پلتفرم و سناریوهای عملی برای متخصصان امنیت و DevOps در سال ۲۰۲۶.
## SOAR چیست و تفاوت با SIEM و XDR
SOAR مخفف Security Orchestration, Automation and Response است. این دسته از پلتفرم‌ها برای اتوماسیون جریان پاسخ به حوادث امنیتی (Incident Response) طراحی شده‌اند. هدف اصلی SOAR کاهش مداخله انسانی در عملیات تکراری و شتاب پاسخ به تهدیدات است.
سه ستون اصلی SOAR عبارتند از:
1. **Orchestration (هماهنگی)**: اتصال و هماهنگی ابزارهای امنیتی مختلف از طریق API، وب‌هک و رابط‌های استاندارد.
2. **Automation (اتوماسیون)**: اجرای دستورالعمل‌ها در صورت برآورده شدن شرایط، با کد یا محیط low-code.
3. **Response (پاسخ)**: اقدامات عملیاتی مثل مسدود کردن آدرس IP، غیرفعال کردن کاربر و جدا کردن میزبان از شبکه.
تفاوت با SIEM: SIEM روی جمع‌آوری لاگ، اندیس‌سازی و ایجاد هشدار تمرکز دارد. SOAR روی پاسخ عملی و اتوماسیون تیکت تمرکز دارد. XDR Detect-and-Response را در لایه اصلی پیشنهاد می‌دهد، اما هماهنگی بین ابزارهای چندتایی در XDR محدودتر است.
### جدول ۱: مقایسه SIEM، XDR و SOAR
| ویژگی | SIEM | XDR | SOAR |
| :--- | :--- | :--- | :--- |
| هدف اصلی | ذخیره و جستجوی لاگ | شناسایی و پاسخ در لایه دارند | هماهنگی و اتوماسیون پاسخ چندتایی |
| ورودی اصلی | لاگ سرور، فایروال، ایمیل | ایندپوینت، شبکه، ابری | هشدار SIEM/EDR، تیکت، ایمیل گزارش |
| خروجی اصلی | هشدل، داشبورد، گزارش | Incident، اقدام پاسخ | پلی‌بوک اجرا شده، تیکت بسته‌شده |
| اتوماسیون پاسخ | محدود یا ندارد | جزئی (در لایه دارند) | زیاد و چندتایی |
| مثال ابزار | Wazuh، Splunk، Sentinel | Microsoft Defender XDR، Falcon | Cortex XSOAR، Splunk SOAR، Tines |
### اجزای اصلی پلتفرم SOAR
یک پلتفرم SOAR capaz شامل چهار لایه است:
- **لایه ورودی (Ingestion)**: دریافت هشدار از Wazuh، Sentinel، Defender، Suricata و گزارش‌های امنیتی.
- **لایه غنی‌سازی (Enrichment)**: استعلام VirusTotal، AbuseIPDB، WHOIS و پلتفرم‌های تهدید برای افزودن Context به IOC.
- **لایه تصمیم (Decision)**: ارزیابی خطر، اجرای playbook و تایید انسانی (Human-in-the-loop) قبل از اقدامات تخریبذیر.
- **لایه اقدام (Action)**: اجرای دستورات در فایروال، ایمیل سرور، ایندپوینت و سیستم تیکتینگ.
### چرخه زندگی Incident در SOAR
1. دریافت هشدار از منبع امنیتی.
2. غنی‌سازی IOC با فید تهدید.
3. امتیازدهی خطر و形成 Incident.
4. اجرای پلی‌بوک یا تایید analyst.
5. انجام اقدامات پاسخ (Block, Isolate, Disable).
6. بسته شدن تیکت و ثبت در پایگاه دانش.
## معیارهای انتخاب پلتفرم SOAR برای سازمان‌های ایرانی
انتخاب پلتفرم SOAR نباید بر اساس نام تجاری انجام شود. تیم امنیت در ایران باید به معیارهای زیر توجه کرد:
### ۱. پشتیبانی از اینتگراسیون و API
پلتفرم باید از API باز برای Wazuh، Sentinel، Microsoft Defender، EDRهای مختلف و سیستم‌های تیکتینگ مانند Jira یا ServiceNow پشتیبانی کند. تعداد اینتگراسیون‌های آماده مهم است، اما امکان نوشتن Custom Connector نیز حیاتی است.
### ۲. مدل لایسنس و هزینه‌های پنهان
برخی پلتفرم‌ها بر اساس تعداد Sitz (کاربر) قیمت‌گذاری می‌کنند، برخی بر اساس تعداد Run یا Data ingestion. هزینه پنهان شامل هزینه connectorها، پشتیبانی و آموزش است.
### ۳. سازگاری با تحریم و محدودیت شبکه
دسترسی به پلتفرم‌های abroad منوط به تحریم است. سازمان‌های ایرانی باید پلتفرم‌هایی را انتخاب کنند که می‌توانند Self-hosted شوند و به فیدهای تهدید محلی متصل شوند.
### جدول ۲: معیارهای انتخاب پلتفرم SOAR
| معیار | اهمیت | چطور ارزیابی شود |
| :--- | :--- | :--- |
| اینتگراسیون با Wazuh/EDR | بالا | لیست Connectorهای آماده و Custom API |
| زبان پلی‌بوک | بالا | YAML، Python، Low-code drag-and-drop |
| Human-in-the-loop | بالا | تایید دستی قبل از اقدامات تخریبذیر |
| لایسنس Self-hosted | بالا | امکان اجرا روی زیرساخت داخلی |
| قیمت کل مالکیت | متوسط | لایسنس + Connector + پشتیبانی + آموزش |
| پشتیبانی فارسی | پایین | مستندات و antarmakedور فارسی |
## معماری اتوماسیون واکنش به حادثه در SOAR
### ورودی و غنی‌سازی داده‌ها
هشدار اولیه معمولاً از SIEM یا EDR می‌آید. در مثال واقعی، سرور Wazuh در یک سازمان با ۱۲۰۰ کاربر در حدود ۸۰۰ هشدار روزانه تولید می‌کند. بدون SOAR، analyst باید هر هشدار را به صورت دستی بررسی کند. با SOAR، ۷۵٪ از هشدارها به صورت خودکار غنی‌سازی و فیلتر می‌شوند.
مثال غنی‌سازی: آدرس IP `185.220.101.42` در هشدار brute force دریافت می‌شود. SOAR آن را در VirusTotal استعلام می‌کند و می‌بیند ۴۲ موتور آنتی‌ویروس آن را malicious گزارش داده‌اند. این Context باعث می‌شود Incident با سطح خطر بالا نشان داده شود.
### اقدامات پاسخ و Human-in-the-loop
اقدامات response در SOAR به سه دسته تقسیم می‌شوند:
- **خودکار**: مسدود کردن IP در فایروال، حذف ایمیل فیشینگ از جعبه ورودی.
- **نیمه خودکار (Human-in-the-loop)**: جدا کردن ایندپوینت از شبکه پس از تایید analyst.
- **دستوری**: ارسال تیکت به تیم شبکه برای بررسی دستی.
## سناریوهای عملی SOAR در محیط Production
در این بخش سه سناریو واقعی با عدد ارائه می‌شود.
### سناریو ۱: ایمیل فیشینگ و پاک‌سازی جعبه ورودی
یک کاربر ایمیل مشکوک دریافت می‌کند. SOAR از طریق پلتفرم ایمیل هشدار می‌گیرد.
مراحل پلی‌بوک:
1. استخراج attached فایل و URLها.
2. استعلام URL در VirusTotal و AbuseIPDB.
3. اگر malicious است، جستجو در تمام جعبه‌های ورودی سازمان و حذف پیام.
4. مسدود کردن فرستادن در Gateway ایمیل.
5. ارسال اعلان به کاربر و analyst.
عدد واقعی: در یک سازمان با ۵۰۰ کارمند، میانگین ۱۲۰۰ ایمیل وارد در ماه است. ۴۵ پیام فیشینگ شناسایی شد. زمان رفع قبل از SOAR: ۶ ساعت. بعد از SOAR: ۱۸ دقیقه.
### سناریو ۲: هشدار EDR از الگو Ransomware
EDR در ایندپوینت الگو رمزگذاری فایل را شناسایی می‌کند.
مراحل:
1. جدا کردن ایندپوینت از شبکه (با تایید Human-in-the-loop).
2. استخراج حافظه و دریافت hash فایل‌های مشکوک.
3. مسدود کردن hash در EDR و فایروال.
4. بازسازی ایندپوینت از بک‌آپ.
عدد واقعی: ۱۵ هشدار ransomware در روز. MTTD قبل از SOAR: ۱۲۰ دقیقه. بعد: ۱۰ دقیقه. MTTR قبل: ۴ ساعت. بعد: ۲۲ دقیقه.
### سناریو ۳: حملات Brute Force به SSH
نظامی Wazuh ۵۰۰ تلاش ناموفق SSH از یک آدرس IP در ۵ دقیقه شناسایی می‌کند.
مراحل:
1. غنی‌سازی IP در AbuseIPDB.
2. اگر خطر بالا است، اضافه کردن به Blacklist فایروال.
3. ارسال لاگ به ticket system.
4. اگر IP داخلی باشد، ارسال هشدار به تیم IT برای بررسی کاربر.
عدد واقعی: ۸۰۰ آدرس IP در ماه مسدود شده. تعداد Incident کاهش یافته از ۴۰۰ به ۱۲ در ماه.
## پیاده‌سازی Playbook در SOAR: گام به گام
در این بخش ۶ گام برای نوشتن اولین پلی‌بوک ارائه می‌شود.
### گام ۱: تعریف Trigger و منبع
ترگر می‌تواند هشدار Wazuh، وب‌هک EDR، یا ایمیل گزارش باشد. منبع و scheme داده‌ها را مشخص کنید.
### گام ۲: نقشه‌ریزی داده‌های ورودی
فیلدهای مهم مانند `src_ip`, `dst_ip`, `user`, `alert_name` را از هشدار استخراج کنید.
### گام ۳: ساخت مراحل غنی‌سازی
است commodity IOCها را در فیدهای تهدید استعلام کنید و نتیجه را به متغیرهای پلی‌بوک اضافه کنید.
### گام ۴: اضافه کردن منطق تصمیم
شرط `if threat_score > 70` را تعریف کنید. برای اقدامات تخریبzier، تایید Human-in-the-loop اضافه کنید.
### گام ۵: تعریف اقدامات پاسخ
برای هر شرط، اقدامات مربوطه را بنویسید: `block_ip`, `isolate_host`, `disable_user`, `create_ticket`.
### گام ۶: تست در محیط Staging و فعال‌سازی در Production
پلی‌بوک را با داده‌های simulate در Staging تست کنید. اگر خطایی نبود، در Production فعال کنید.
کد نمونه یک پلی‌بوک YAML برای Cortex XSOAR:
```yaml
playbookName: Phishing Email Response
inputs:
- email_id
- sender
- subject
tasks:
- id: 1
taskName: Extract URLs
type: command
command: extract-urls
arguments:
email_id: ${inputs.email_id}
- id: 2
taskName: Reputation Check
type: command
command: url-reputation
arguments:
url: ${tasks.1.outputs.urls}
conditions:
- condition: malicious == true
nextTaskId: 3
- id: 3
taskName: Block Sender
type: command
command: block-email-sender
arguments:
sender: ${inputs.sender}
requiresApproval: true
```
کد نمونه curl برای فراخوانی API SOAR:
```bash
curl -X POST https://soar.internal/api/v1/playbooks/phishing-response/run \
-H "Authorization: Bearer $SOAR_API_KEY" \
-H "Content-Type: application/json" \
-d '{"email_id":"msg-12345","sender":"attacker@example.com","subject":"Invoice Payment"}'
```
کد نمونه Python برای غنی‌سازی IP:
```python
import requests
def enrich_ip(ip, api_key):
url = f"https://www.virustotal.com/api/v3/ip_addresses/{ip}"
headers = {"x-apikey": api_key}
r = requests.get(url, headers=headers)
return r.json()
# استفاده
result = enrich_ip("185.220.101.42", "vt_api_key_here")
print(result)
```
## چالش‌های استقرار SOAR در ایران و راهکارها
### تحریم و دسترسی به پلتفرم‌های تجاری
چندین پلتفرم معتبر مانند Cortex XSOAR و Splunk SOAR به دلیل تحریم، لایسنس رسمی برای ایران ارائه نمی‌دهند. راهکار: استفاده از نسخه Self-hosted با آپدیت از طریق مخازن داخلی یا پلتفرم‌های مفتوح مثل Shuffle، Tines Community و n8n.
### محدودیت دسترسی به اینترنت و فیدهای تهدید
استعلام VirusTotal و AbuseIPDB ممکن است مسدود باشد. راهکار: استفاده از Proxy یا فیدهای تهدید محلی (مثل ThreatFeeds IR) و ذخیره IOC در دیتابیس داخلی.
### gaps و مستندات فارسی
کمبود متخصص آشنایی با SOAR و عدم وجود مستندات فارسی مشکل است. راهکار: آموزش داخلی، ترجمه مستندات Splunk SOAR و Cortex XSOAR، و ایجاد Knowledge base سازمانی.
## سنجش کارایی SOAR: KPI، MTTD و MTTR
بعد از استقرار SOAR، باید معیارهای زیر را اندازه بگیرید:
### جدول ۳: KPI قبل و بعد از استقرار SOAR
| KPI | قبل از SOAR | بعد از SOAR | تغییر |
| :--- | :--- | :--- | :--- |
| MTTD (دقيقة) | 150 | 14 | -۹۰٪ |
| MTTR (دقيقة) | 240 | 22 | -۹۰٪ |
| تیکت‌های باز در ماه | ۴۰۰ | ۱۲ | -۹۷٪ |
| درصدfalse-positive | ۳۵٪ | ۸٪ | -۷۷٪ |
| تعداد پلی‌بوک اجرا شده در ماه | ۰ | ۳۲۰ | + infinite |
### معیارهای مهم
- **MTTD**: میانگین زمان شناسایی Incident.
- **MTTR**: میانگین زمان رفع Incident.
- **Playbook Execution Rate**: تعداد اجراهای پلی‌بوک در نسبت به تعداد Incident.
- **False Positive Rate**: درصد هشدارهای غلط.
## مقایسه پلتفرم‌های SOAR: مفتوح و تجاری
### جدول ۴: مقایسه پلتفرم‌های SOAR
| پلتفرم | لایسنس | استقرار | اینتگراسیون | زبان پلی‌بوک | قیمت تخمینی |uitable برای |
| :--- | :--- | :--- | :--- | :--- | :--- | :--- |
| Cortex XSOAR | تجاری | Self-hosted / ابری | بسیار زیاد | Python / YAML | بالا | سازمان‌های بزرگ با بودجه بالا |
| Splunk SOAR | تجاری | Self-hosted / ابری | زیاد | Python | بالا | کاربران Splunk |
| Tines | تجاری / رایگان برای محدود | ابری | متوسط | Low-code | متوسط | تیم‌های کوچک و متوسط |
| Swimlane | تجاری | Self-hosted | زیاد | Python / YAML | بالا | سازمان‌های اداری |
| Shuffle | مفتوح (MIT) | Self-hosted | متوسط | Python / YAML | رایگان / پولی | تیم‌های با بودجه محدود |
| n8n + Custom | ouvert | Self-hosted | قابل تنظیم | JavaScript / Python | پایین | تیم‌های DevSecOps |
## جمع‌بندی
SOAR جایگزین analyst نیست، بلکه تقویت‌کننده آن است. با پلی‌بوک‌های goed طراحی، می‌توانMTTD و MTTR را به شدت کاهش داد و analyst را از عملیات تکراری خلاصی داد. برای سازمان‌های ایرانی، انتخاب پلتفرم باید بر اساس اینتگراسیون، لایسنس Self-hosted و قابلیت فید تهدید محلی باشد. پیاده‌سازی گام به گام و سنجش KPIها تضمین‌کننده موفقیت است.
برای شروع، به [مقاله Incident Response Playbook](https://aidenweb.ir/blog/incident-response-playbook) مراجعه کنید تا چگونگی پاسخ به Incident را درک کنید، سپس [راه‌اندازی Wazuh SIEM](https://aidenweb.ir/blog/wazuh-siem) را مطالعه کنید تا منبع هشدار برای SOAR داشته باشید. در نهایت، [مقایسه EDR vs XDR vs MDR](https://aidenweb.ir/blog/edr-vs-xdr-vs-mdr) به شما کمک می‌کند لایه تشخیص مناسبی انتخاب کنید. همچنین [نوشتن Sigma Rules](https://aidenweb.ir/blog/sigma-rules-blue-team) می‌تواند منبع هشدار دقیق‌تری برای SOAR فراهم کند.