در دنیای امروز، امنیت سایبری دیگر فقط به نصب Firewall، Antivirus یا WAF محدود نمیشود. سازمانها بهصورت مداوم با حجم بزرگی از رویدادهای امنیتی، لاگها، هشدارها، رفتارهای مشکوک، تلاشهای ورود غیرمجاز، آسیبپذیریها و حملات سایبری مواجه هستند. مسئله اصلی این است که چه کسی باید این اطلاعات را بهصورت مداوم بررسی کند، تهدید واقعی را از هشدارهای بیاهمیت تشخیص دهد و در صورت وقوع حمله، سریع و دقیق واکنش نشان دهد؟
اینجاست که SOC یا Security Operations Center وارد میشود.
SOC یک واحد عملیاتی و تخصصی برای پایش، تشخیص، تحلیل و پاسخ به تهدیدها و رخدادهای امنیتی است. SOC میتواند بهصورت یک تیم داخلی در سازمان فعالیت کند یا بهصورت سرویس Managed SOC یا Managed Detection and Response (MDR) توسط یک ارائهدهنده تخصصی ارائه شود.
اما SOC صرفاً یک اتاق پر از مانیتور و چند داشبورد SIEM نیست. یک SOC بالغ ترکیبی از افراد، فرآیندها، فناوری، داده، Threat Intelligence، Detection Engineering، Incident Response و اتوماسیون است که در کنار یکدیگر یک قابلیت عملیاتی برای دفاع سایبری ایجاد میکنند.
SOC چیست؟
SOC یا Security Operations Center مرکز یا واحدی است که مسئولیت عملیات روزمره امنیت سایبری یک سازمان را بر عهده دارد.
مأموریت اصلی SOC را میتوان در چند فعالیت خلاصه کرد:
- جمعآوری و پایش رویدادهای امنیتی
- تشخیص رفتارها و الگوهای مشکوک
- تحلیل و اولویتبندی هشدارهای امنیتی
- تحقیق درباره رخدادهای مشکوک
- Threat Hunting یا جستوجوی فعالانه برای تهدیدها
- پاسخ به Incidentهای امنیتی
- هماهنگی با تیمهای Infrastructure، DevOps، Network، Application و IT
- بهبود مستمر Detectionها و کنترلهای امنیتی
- ثبت و گزارش رخدادها و شاخصهای امنیتی
بنابراین SOC را میتوان مرکز عملیاتی دفاع سایبری سازمان دانست؛ جایی که اطلاعات امنیتی از منابع مختلف جمعآوری میشود و تیم امنیت بر اساس آنها تصمیم میگیرد چه چیزی طبیعی، چه چیزی مشکوک و چه چیزی یک Incident واقعی است.
چرا سازمانها به SOC نیاز دارند؟
در معماریهای مدرن، یک سازمان ممکن است دهها یا صدها منبع تولیدکننده اطلاعات امنیتی داشته باشد:
- Firewall و NGFW
- WAF
- VPN
- Active Directory و Identity Provider
- Linux و Windows Server
- Kubernetes و Containerها
- Cloud Platform
- Databaseها
- Endpointها و لپتاپهای کاربران
- EDR/XDR
- Application و APIها
- DNS
- Proxy و Load Balancer
- IDS/IPS
- Email Security
- Cloud Security Platform
هرکدام از این سیستمها میتوانند صدها، هزاران یا حتی میلیونها Event تولید کنند. بررسی دستی این حجم از اطلاعات عملاً امکانپذیر نیست.
در نتیجه، سازمان به یک سیستم و تیم نیاز دارد که این دادهها را جمعآوری، Normalization، Correlation، تحلیل و اولویتبندی کند و در نهایت مهمترین موارد را به تحلیلگر امنیتی برساند.
SOC دقیقاً برای حل همین مسئله ساخته شده است.
SOC چه تفاوتی با SIEM دارد؟
یکی از رایجترین اشتباهات این است که SOC و SIEM را یک چیز بدانیم.
SIEM یک فناوری است؛ SOC یک قابلیت عملیاتی.
SIEM وظیفه جمعآوری و تحلیل دادههای امنیتی از منابع مختلف را بر عهده دارد و میتواند با استفاده از Rule، Correlation، Detection و Analytics هشدارهای امنیتی ایجاد کند.
اما SOC از SIEM، نیروی انسانی، فرآیندهای Incident Response، Threat Intelligence، EDR/XDR، SOAR، Ticketing، Playbook و ابزارهای دیگر استفاده میکند تا یک فرآیند کامل دفاع سایبری شکل بگیرد.
| مفهوم | نقش اصلی |
|---|---|
| SOC | تیم و قابلیت عملیاتی برای پایش، تشخیص، تحلیل و پاسخ امنیتی |
| SIEM | جمعآوری، ذخیره، Correlation و تحلیل Eventهای امنیتی |
| SOAR | اتوماسیون و Orchestration فرآیندهای امنیتی و Response |
| EDR | تشخیص و پاسخ در Endpointها |
| XDR | Correlation و Detection/Response در چند حوزه امنیتی مانند Endpoint، Identity، Email و Network |
| CSIRT | تمرکز تخصصی بر مدیریت و پاسخ به Incidentهای امنیتی |
| Threat Intelligence | تأمین و تحلیل اطلاعات درباره تهدیدها، مهاجمان و Indicators |
اجزای اصلی یک SOC
یک SOC حرفهای را میتوان از چند لایه اصلی تشکیلشده دانست:
- People — افراد و نقشهای تخصصی
- Process — فرآیندها، Playbookها و روشهای عملیاتی
- Technology — ابزارهای Detection، Monitoring و Response
- Data — لاگها، Eventها، Telemetry و Threat Intelligence
- Governance — سیاستها، مسئولیتها، Risk Management و Reporting
اگر یکی از این اجزا وجود نداشته باشد، SOC الزاماً قابلیت دفاع مؤثر ایجاد نمیکند. برای مثال، خرید یک SIEM قدرتمند بدون داشتن Log Source مناسب، Detectionهای صحیح و تحلیلگر متخصص، بهتنهایی SOC ایجاد نمیکند.
معماری SOC چگونه است؟
یک معماری متداول SOC را میتوان به این شکل تصور کرد:
Security & Infrastructure Sources
│
├── Firewall / WAF
├── Servers
├── Endpoints / EDR
├── Identity / IAM
├── Cloud / Kubernetes
├── Applications / APIs
├── Network / DNS / VPN
└── Databases
│
▼
Log Collection & Telemetry
│
▼
Normalization / Enrichment
│
▼
SIEM
│
┌───────┴────────┐
▼ ▼
Detection Correlation
Analytics & Rules
│ │
└───────┬────────┘
▼
Alerts
│
▼
SOC Analyst / Triage
│
┌───────┼─────────┐
▼ ▼ ▼
Investigate Hunt Escalate
│ │
└────────┬────────┘
▼
Incident Response
│
▼
Containment / Eradication
│
▼
Recovery
│
▼
Lessons Learned
Detection Tuning
در معماریهای مدرن، لایه SOAR نیز میتواند در بخشهای مختلف این جریان قرار بگیرد تا اقدامات تکراری بهصورت خودکار انجام شوند.
فرآیند کاری SOC چگونه است؟
فعالیت SOC معمولاً یک چرخه دائمی است و فقط به «دیدن Alert» محدود نمیشود.
۱. جمعآوری داده
اولین مرحله، دریافت داده از منابع مختلف است.
برای مثال:
- Loginهای موفق و ناموفق
- تغییرات Privilege
- اتصال به VPN
- درخواستهای WAF
- Firewall Eventها
- Process Execution
- Network Connection
- DNS Query
- API Request
- Cloud Activity
- تغییرات Kubernetes
کیفیت این مرحله اهمیت زیادی دارد. اگر سازمان Log مناسب تولید نکند یا Logها بدون Context وارد سیستم شوند، حتی بهترین تحلیلگر امنیتی نیز دید کاملی به محیط نخواهد داشت.
۲. Normalization و Enrichment
دادههای امنیتی از منابع مختلف با Formatهای متفاوت وارد SOC میشوند.
بنابراین لازم است دادهها تا حد امکان Normalize شوند تا بتوان آنها را در کنار یکدیگر تحلیل کرد.
در مرحله Enrichment نیز میتوان اطلاعات بیشتری به Event اضافه کرد؛ برای مثال:
- اطلاعات Asset
- Identity کاربر
- GeoIP
- Threat Intelligence
- Domain Reputation
- Severity
- اطلاعات مالک سرویس
۳. Detection
در این مرحله SOC تلاش میکند الگوهای مشکوک را شناسایی کند.
Detection میتواند بر اساس Ruleهای مشخص، Correlation، Behavioral Analytics، Threat Intelligence، Machine Learning یا Analytics مبتنی بر تکنیکهای مهاجمان انجام شود.
برای مثال، یک Login ناموفق بهتنهایی ممکن است اهمیت چندانی نداشته باشد. اما اگر در کنار آن موارد زیر دیده شود:
- صدها Login ناموفق
- از چند IP مختلف
- برای یک حساب حساس
- سپس یک Login موفق
- و بلافاصله افزایش Privilege
ترکیب این Eventها میتواند یک Incident مهم ایجاد کند.
۴. Triage
هر Alert الزاماً یک حمله واقعی نیست.
تحلیلگر SOC ابتدا باید مشخص کند که Alert:
- False Positive است؛
- یک رفتار طبیعی ولی غیرمعمول است؛
- یک Security Event کماهمیت است؛
- یا نشانه یک Incident واقعی است.
این مرحله یکی از مهمترین بخشهای عملیات SOC است، زیرا تعداد زیاد Alertهای کمکیفیت میتواند باعث Alert Fatigue شود.
۵. Investigation
اگر Alert اهمیت داشته باشد، تحلیلگر باید Context بیشتری جمعآوری کند.
در این مرحله ممکن است مواردی مانند Process Tree، Network Connection، Authentication History، DNS Query، Endpoint Telemetry، Cloud Activity و Application Log بررسی شوند.
۶. Incident Response
اگر رخداد بهعنوان Incident شناسایی شود، فرآیند Response آغاز میشود.
بسته به نوع حادثه ممکن است اقدامات زیر انجام شوند:
- Disable کردن حساب کاربری
- Reset کردن Credential
- Isolate کردن Endpoint
- Block کردن IP یا Domain
- مسدود کردن یک Indicator
- قطع ارتباط یک Host
- رفع Persistence
- حذف Malware
- Patch کردن آسیبپذیری
- بررسی Scope حمله
- حفظ شواهد برای Forensics
در Incidentهای مهم، SOC معمولاً با تیمهای Infrastructure، Network، Application، Legal، Management و در صورت نیاز تیمهای تخصصی Incident Response همکاری میکند.
۷. Recovery و Lessons Learned
بعد از Containment و رفع تهدید، کار SOC تمام نمیشود.
باید مشخص شود:
- مهاجم چگونه وارد شد؟
- چه سیستمهایی تحت تأثیر قرار گرفتند؟
- چرا Detection اولیه نتوانست تهدید را شناسایی کند؟
- چه کنترل امنیتی باید اصلاح شود؟
- چه Detection جدیدی باید ایجاد شود؟
- چه چیزی در فرآیند Incident Response باید تغییر کند؟
به این ترتیب، Incident به یک منبع یادگیری برای افزایش قابلیت دفاعی سازمان تبدیل میشود.
تیم SOC از چه افرادی تشکیل میشود؟
ساختار تیم SOC بسته به اندازه سازمان و مدل عملیاتی آن متفاوت است؛ بنابراین یک ساختار واحد و اجباری برای همه سازمانها وجود ندارد.
با این حال، نقشهای زیر در SOCهای حرفهای بسیار رایج هستند.
SOC Analyst Tier 1
Tier 1 معمولاً نقطه ورود Alertها به تیم SOC است.
وظایف معمول این نقش شامل:
- پایش Alertها
- Initial Triage
- بررسی Context اولیه
- Classification
- ایجاد Ticket
- Escalation موارد مشکوک
- اجرای Playbookهای استاندارد
SOC Analyst Tier 2
تحلیلگر Tier 2 معمولاً Investigation عمیقتری انجام میدهد و در صورت نیاز روی Incidentهای پیچیدهتر کار میکند.
- تحلیل چندمنبعی Eventها
- بررسی Timeline
- تحلیل Endpoint و Network
- Incident Investigation
- تأیید یا رد Detection
- Escalation به Tier 3 یا Incident Response
Tier 3 / Senior Analyst / Threat Hunter
این سطح بیشتر با Incidentهای پیچیده، Threat Hunting و Detection Engineering سروکار دارد.
Threat Hunter بهجای اینکه منتظر Alert بماند، بهصورت فعالانه به دنبال شواهد حمله یا رفتارهای غیرعادی در محیط میگردد.
MITRE ATT&CK نیز میتواند برای طراحی و ارزیابی Detectionها بر اساس تکنیکها و رفتارهای مهاجمان مورد استفاده قرار گیرد.
SOC Engineer
SOC Engineer مسئول بخش مهمی از زیرساخت فنی SOC است.
برای مثال:
- راهاندازی و نگهداری SIEM
- اتصال Log Sourceها
- Parsing و Normalization
- ساخت Detection Rule
- مدیریت Retention
- بهینهسازی Pipeline لاگ
- Integration با EDR/XDR
- پیادهسازی SOAR
- Automation
Threat Intelligence Analyst
این نقش روی اطلاعات مربوط به تهدیدها و مهاجمان تمرکز میکند.
Threat Intelligence میتواند شامل اطلاعاتی درباره IP، Domain، Hash، Malware، Campaign، Actor و TTPهای مرتبط با تهدیدها باشد.
Incident Responder
Incident Responder در زمان وقوع Incidentهای جدی وارد عمل میشود و روی Containment، Eradication، Forensics و Recovery همکاری میکند.
در برخی سازمانها Incident Response بخشی از SOC است و در برخی دیگر بهصورت تیمی مانند CSIRT در کنار SOC فعالیت میکند.
SOC Manager
SOC Manager مسئول مدیریت کلی عملیات SOC است و معمولاً روی مواردی مانند SLA، نیروی انسانی، فرآیندها، Reporting، Training، Risk و هماهنگی با سایر واحدها تمرکز دارد.
Tier 1، Tier 2 و Tier 3 دقیقاً چه تفاوتی دارند؟
| سطح | تمرکز | نمونه فعالیت |
|---|---|---|
| Tier 1 | Monitoring & Triage | بررسی Alert، Classification و Escalation |
| Tier 2 | Investigation | تحلیل عمیق Incident و Correlation دادهها |
| Tier 3 | Advanced Analysis & Hunting | Threat Hunting، Detection Engineering و Incidentهای پیچیده |
| Security Engineer | Technology | SIEM، SOAR، EDR، Integration و Automation |
| Incident Response | Response | Containment، Eradication، Forensics و Recovery |
این Tierها بیشتر یک مدل عملیاتی رایج هستند و نباید آنها را یک استاندارد ثابت برای تمام SOCها در نظر گرفت. در SOCهای کوچک ممکن است یک نفر چند نقش را همزمان بر عهده داشته باشد.
SIEM در SOC چه نقشی دارد؟
SIEM یا Security Information and Event Management یکی از اجزای کلیدی بسیاری از SOCها است.
SIEM دادههای امنیتی را از منابع مختلف جمعآوری میکند و امکان جستوجو، Correlation، Alerting و تحلیل آنها را فراهم میکند.
نمونه منابعی که میتوانند به SIEM متصل شوند:
- Linux Syslog
- Windows Security Events
- Firewall
- WAF
- EDR
- VPN
- IAM
- DNS
- Cloud Audit Logs
- Kubernetes Audit Logs
- Application Logs
- Database Audit Logs
اما داشتن SIEM بهتنهایی به معنی داشتن SOC نیست. اگر Logها کیفیت مناسبی نداشته باشند، Detectionها ضعیف باشند یا کسی Alertها را تحلیل نکند، SIEM صرفاً حجم بزرگی از داده تولید خواهد کرد.
SOAR چیست و چه کمکی به SOC میکند؟
SOAR یا Security Orchestration, Automation and Response برای خودکارسازی و هماهنگسازی بخشی از فرآیندهای امنیتی استفاده میشود.
فرض کنید یک Alert با Confidence بالا درباره یک IP مخرب ایجاد شده است. بهجای اینکه تحلیلگر بهصورت دستی:
- IP را بررسی کند؛
- در Threat Intelligence جستوجو کند؛
- Ticket ایجاد کند؛
- IP را روی Firewall Block کند؛
- Endpointهای مرتبط را بررسی کند؛
- گزارش ایجاد کند؛
میتوان بخشهایی از این فرآیند را با یک Playbook خودکار کرد.
SOAR باعث میشود تحلیلگران زمان بیشتری برای Investigationهای پیچیده داشته باشند و عملیاتهای تکراری سریعتر انجام شوند.
XDR چه تفاوتی با SIEM دارد؟
XDR یا Extended Detection and Response تلاش میکند سیگنالهای امنیتی را در چند حوزه مختلف با یکدیگر مرتبط کند؛ برای مثال Endpoint، Identity، Email، Cloud و Network.
در یک معماری مدرن، SIEM و XDR الزاماً رقیب یکدیگر نیستند و میتوانند در کنار هم استفاده شوند.
برای مثال:
- XDR روی Telemetry و Detection تخصصی Endpoint و سایر Security Controlها تمرکز میکند.
- SIEM دید وسیعتری روی دادههای سازمان و منابع مختلف ایجاد میکند.
- SOAR میتواند Response را بین ابزارهای مختلف Orchestrate کند.
Threat Hunting در SOC چیست؟
در Monitoring سنتی، تیم SOC منتظر میماند تا یک Rule یا Detection یک Alert تولید کند.
اما در Threat Hunting، تحلیلگر بهصورت فعالانه به دنبال نشانههای حمله میگردد؛ حتی زمانی که Alert مشخصی وجود ندارد.
برای مثال، Threat Hunter ممکن است بررسی کند:
- آیا حسابی با رفتار غیرعادی وجود دارد؟
- آیا یک Process غیرمعمول روی تعداد زیادی Server اجرا شده است؟
- آیا Endpointهایی به Domainهای ناشناخته متصل شدهاند؟
- آیا Privilege یک حساب بدون دلیل افزایش یافته است؟
- آیا الگوی خاصی از DNS Query در محیط مشاهده میشود؟
MITRE ATT&CK یکی از منابع مهم برای طراحی Detection و Hunting بر اساس رفتارها و تکنیکهای شناختهشده مهاجمان است.
SOC و Incident Response چه تفاوتی دارند؟
SOC و Incident Response ارتباط نزدیکی دارند اما یکی نیستند.
SOC یک قابلیت دائمی برای Monitoring، Detection، Analysis و هماهنگی Response است.
Incident Response روی مدیریت و پاسخ به یک رخداد امنیتی مشخص تمرکز دارد.
بهصورت ساده:
SOC
│
├── Monitoring
├── Detection
├── Triage
├── Threat Hunting
├── Threat Intelligence
└── Incident Detection
│
▼
Incident Response
│
├── Investigation
├── Containment
├── Eradication
├── Recovery
└── Lessons Learned
در برخی سازمانها این دو در یک تیم قرار دارند و در سازمانهای بزرگتر ممکن است SOC و CSIRT ساختارهای جداگانه ولی کاملاً هماهنگ داشته باشند.
SOC و NOC چه تفاوتی دارند؟
NOC یا Network Operations Center و SOC هر دو عملیات 24/7 را ممکن است انجام دهند، اما هدف آنها متفاوت است.
| موضوع | NOC | SOC |
|---|---|---|
| تمرکز اصلی | Availability و Performance | Security و Threat Detection |
| مثال Alert | Packet Loss یا Down شدن سرویس | Brute Force یا رفتار مشکوک |
| ابزارهای رایج | Monitoring، NMS، APM | SIEM، EDR، XDR، SOAR |
| هدف | پایداری و دسترسپذیری | کاهش Risk و Impact حملات |
در معماریهای مدرن، همکاری NOC، SOC، DevOps، SRE و تیم زیرساخت اهمیت زیادی دارد؛ زیرا بسیاری از رخدادها همزمان اثر عملیاتی و امنیتی دارند.
SOC و DevSecOps چه ارتباطی دارند؟
SOC نباید یک جزیره جدا از تیم توسعه و زیرساخت باشد.
در محیطهای مدرن که از CI/CD، Kubernetes، Cloud و Microservices استفاده میشود، بسیاری از Security Signalها از همان زیرساختهایی تولید میشوند که تیم DevOps مدیریت میکند.
به همین دلیل SOC میتواند با DevSecOps در زمینههایی مانند موارد زیر همکاری کند:
- Security Logging
- Audit Logging
- Container Security
- Image Scanning
- Secrets Management
- Vulnerability Management
- Infrastructure Hardening
- Cloud Security
- Kubernetes Security
- Security Gates در CI/CD
برای آشنایی بیشتر با این رویکرد میتوانید مقاله DevSecOps چیست؟ را نیز مطالعه کنید.
SOC برای Kubernetes و Cloud چگونه کار میکند؟
در معماریهای Cloud Native، منابع امنیتی فقط Server و Firewall نیستند.
SOC باید بتواند مواردی مانند موارد زیر را نیز مشاهده و تحلیل کند:
- Kubernetes Audit Logs
- API Server Events
- Cloud Audit Logs
- IAM Events
- Container Runtime Events
- Ingress و API Gateway Logs
- Network Flow
- Application Telemetry
- Secrets Access
برای مثال، یک تغییر ناگهانی در RBAC، ایجاد یک Service Account جدید، تغییر Privilege یا اجرای Container غیرعادی میتواند از نظر امنیتی اهمیت زیادی داشته باشد.
به همین دلیل، SOC مدرن باید درک مناسبی از Cloud، Kubernetes، Linux، Network و Application Architecture داشته باشد.
اهمیت Log Management در SOC
یکی از پایههای یک SOC موفق، داشتن Log Management مناسب است.
لاگ بدون Context میتواند ارزش محدودی داشته باشد. از طرف دیگر، جمعآوری همه لاگها بدون طراحی صحیح نیز میتواند هزینه Storage و Processing را بهشدت افزایش دهد.
برای طراحی Log Management باید مواردی مانند اینها مشخص شوند:
- چه Logهایی باید جمعآوری شوند؟
- Retention هر Log چقدر است؟
- کدام Logها باید به SIEM ارسال شوند؟
- کدام Logها فقط برای Troubleshooting نگهداری میشوند؟
- چه اطلاعات حساسی نباید وارد Log شود؟
- آیا Logها Tamper-resistant هستند؟
- آیا Timestampها هماهنگ هستند؟
- آیا امکان جستوجوی سریع وجود دارد؟
در کنار SIEM، ابزارهای Observability مانند Grafana، Prometheus و سیستمهای Log Management نیز میتوانند در معماری کلی Monitoring و Operations سازمان نقش داشته باشند؛ البته Monitoring عملیاتی با Security Monitoring یکسان نیست و باید مرزهای آنها مشخص باشد.
SOC و Threat Intelligence
Threat Intelligence به SOC کمک میکند Detectionها را با اطلاعات بیشتری درباره تهدیدهای شناختهشده غنی کند.
برای مثال، یک Event شامل یک IP بهتنهایی ممکن است معنای خاصی نداشته باشد. اما اگر آن IP در یک Feed معتبر بهعنوان Indicator مرتبط با یک Campaign مخرب شناخته شده باشد، اولویت Event میتواند تغییر کند.
Threat Intelligence میتواند شامل:
- IP Address
- Domain
- URL
- File Hash
- Malware Family
- Threat Actor
- Campaign
- TTP
باشد.
البته استفاده از Threat Intelligence باید با Context داخلی سازمان ترکیب شود؛ هر Indicator خارجی لزوماً به معنی وجود Incident در محیط داخلی نیست.
SOC 24/7 چیست؟
بسیاری از سازمانها به دلیل اهمیت سرویسهای خود نیاز دارند Monitoring امنیتی آنها در تمام ساعات شبانهروز انجام شود.
در یک SOC 24/7، پوشش عملیاتی میتواند با مدلهای مختلفی انجام شود:
- چند شیفت داخلی
- تیم داخلی + On-Call
- ترکیب تیم داخلی و Managed SOC
- برونسپاری کامل Monitoring و Escalation
- Follow-the-Sun در سازمانهای چندمنطقهای
اما «24/7 بودن» صرفاً به معنی روشن بودن داشبورد در تمام ساعات شبانهروز نیست. باید مشخص باشد در ساعتهای مختلف چه کسی Alert را دریافت میکند، چه SLAای برای Triage وجود دارد و در Incidentهای Critical چه کسی اختیار اقدام دارد.
مدلهای پیادهسازی SOC
۱. Internal SOC
در این مدل سازمان تیم SOC را خودش استخدام و مدیریت میکند.
مزایا:
- کنترل بیشتر
- شناخت عمیقتر از محیط داخلی
- امکان طراحی فرآیند کاملاً اختصاصی
- کنترل بیشتر روی دادههای امنیتی
چالشها:
- هزینه نیروی انسانی
- نیاز به پوشش شیفتی
- جذب متخصصان امنیت
- هزینه ابزارها
- نیاز به آموزش و نگهداری مداوم
۲. Managed SOC
در این مدل، بخشی یا کل عملیات SOC توسط یک شرکت تخصصی انجام میشود.
این مدل میتواند برای سازمانهایی مناسب باشد که نمیخواهند از ابتدا یک تیم کامل SOC ایجاد کنند یا به پوشش 24/7 نیاز دارند اما ظرفیت استخدام و مدیریت چندین نیروی تخصصی را ندارند.
در یک Managed SOC حرفهای باید دقیقاً مشخص باشد:
- چه چیزهایی Monitor میشوند؟
- چه Log Sourceهایی پوشش داده میشوند؟
- SLA چیست؟
- Severityها چگونه تعریف میشوند؟
- Escalation چگونه انجام میشود؟
- در Incident چه کسی مجاز به اقدام است؟
- چه گزارشهایی ارائه میشود؟
- Retention دادهها چقدر است؟
- دادهها کجا نگهداری میشوند؟
۳. Hybrid SOC
در این مدل بخشی از عملیات توسط تیم داخلی و بخشی توسط شریک بیرونی انجام میشود.
برای مثال:
- تیم داخلی مسئول Incident Response باشد.
- تیم بیرونی Monitoring 24/7 را انجام دهد.
- تیم داخلی Detection Engineering را مدیریت کند.
- Threat Hunting بهصورت مشترک انجام شود.
SOC-as-a-Service و MDR چه تفاوتی دارند؟
این دو مفهوم در بازار گاهی بهجای یکدیگر استفاده میشوند اما دقیقاً یکسان نیستند.
SOC-as-a-Service معمولاً بر ارائه قابلیتهای SOC مانند Monitoring، Analysis، Alerting و Reporting تمرکز دارد.
MDR یا Managed Detection and Response معمولاً بر Detection و Response فعالتر تمرکز دارد و میتواند شامل Investigation، Threat Hunting و اقدامات Response نیز باشد.
بنابراین هنگام مقایسه سرویسها بهتر است بهجای توجه صرف به عنوان سرویس، دقیقاً بررسی کنید چه قابلیتهایی در قرارداد و SLA ارائه میشوند.
SOC چه KPIهایی دارد؟
موفقیت SOC را نباید فقط با تعداد Alertها یا تعداد Incidentهای شناساییشده سنجید.
برخی از Metrics مهم عبارتاند از:
| Metric | مفهوم |
|---|---|
| MTTD | میانگین زمان لازم برای Detect کردن یک رخداد |
| MTTR | زمان لازم برای پاسخ و بازگرداندن شرایط به وضعیت مناسب |
| Mean Time to Triage | زمان لازم برای بررسی اولیه Alert |
| False Positive Rate | نسبت هشدارهای غیرواقعی یا کمارزش |
| Detection Coverage | میزان پوشش تهدیدها و تکنیکهای موردنظر |
| Escalation Rate | نسبت Alertهایی که به سطوح بالاتر منتقل میشوند |
| Automation Rate | میزان اقداماتی که بدون عملیات دستی انجام میشوند |
| Log Source Coverage | میزان پوشش منابع مهم لاگ و Telemetry |
مهم است که KPIها متناسب با اهداف سازمان تعریف شوند. NIST نیز در راهنمای اندازهگیری امنیت اطلاعات بر انتخاب و اعتبارسنجی معیارهایی تأکید میکند که بتوانند برای ارزیابی واقعی عملکرد کنترلها و برنامه امنیتی استفاده شوند.
Alert زیاد لزوماً به معنی SOC خوب نیست
یکی از اشتباهات رایج در طراحی SOC این است که موفقیت را با تعداد Alertهای تولیدشده اندازهگیری کنیم.
فرض کنید یک SOC روزانه یک میلیون Alert تولید میکند. اگر تحلیلگران نتوانند آنها را بررسی کنند، این حجم زیاد داده عملاً مزیت محسوب نمیشود.
هدف باید ایجاد High-Quality Detection باشد؛ یعنی Alertها تا حد امکان:
- Relevant باشند؛
- Context داشته باشند؛
- Severity مناسبی داشته باشند؛
- قابل Investigation باشند؛
- و در صورت امکان با Automation پردازش شوند.
به همین دلیل، یکی از فعالیتهای دائمی SOC باید Detection Tuning باشد.
Playbook در SOC چیست؟
Playbook یک دستورالعمل عملیاتی برای برخورد با یک سناریوی مشخص امنیتی است.
برای مثال یک Playbook برای Compromised Account میتواند شامل مراحل زیر باشد:
- تأیید Alert
- بررسی Loginهای اخیر
- بررسی IP و Location
- بررسی MFA
- بررسی فعالیتهای انجامشده توسط حساب
- بررسی Privilegeها
- Disable یا Lock کردن Account در صورت نیاز
- Reset کردن Credential
- بررسی Scope
- ثبت Incident
- Lessons Learned
Playbookهای استاندارد باعث میشوند Response قابل پیشبینیتر، سریعتر و قابل ممیزیتر شود.
SOC چگونه با NIST CSF کار میکند؟
NIST Cybersecurity Framework 2.0 شش Function اصلی دارد:
- Govern
- Identify
- Protect
- Detect
- Respond
- Recover
SOC بیشتر در بخشهای Detect، Respond و بخشی از Recover نقش مستقیم دارد، اما برای عملکرد صحیح باید با Identify، Protect و Govern نیز ارتباط داشته باشد.
برای مثال اگر سازمان Assetهای خود را نمیشناسد، SOC نمیتواند بهدرستی تعیین کند کدام Alert مربوط به یک سیستم Critical است. یا اگر فرآیند Response مشخص نباشد، حتی Detection صحیح نیز الزاماً به کاهش Impact منجر نمیشود.
بنابراین SOC را باید بخشی از یک Cybersecurity Program بزرگتر دانست، نه جایگزین کل برنامه امنیتی سازمان.
SOC و ISO 27001
SOC میتواند در اجرای بخشی از کنترلها و الزامات امنیت اطلاعات به سازمان کمک کند، اما داشتن SOC بهتنهایی به معنی انطباق با ISO 27001 نیست.
برای مثال SOC میتواند در حوزههایی مانند:
- Monitoring
- Incident Management
- Logging
- Security Event Detection
- Access Monitoring
- Evidence Collection
- Continuous Improvement
نقش مهمی داشته باشد.
برای آشنایی بیشتر با استاندارد ISO 27001 میتوانید مقاله ISO 27001 چیست؟ را مطالعه کنید.
SOC و Vulnerability Management
Vulnerability Management و SOC دو قابلیت متفاوت اما مرتبط هستند.
Vulnerability Management تلاش میکند آسیبپذیریهای موجود در سیستمها را شناسایی و مدیریت کند، در حالی که SOC بیشتر روی Detection و Response نسبت به رخدادها و تهدیدهای امنیتی تمرکز دارد.
اما این دو سیستم میتوانند اطلاعات یکدیگر را Enrich کنند.
برای مثال، یک Alert روی سروری که یک آسیبپذیری Critical دارد، ممکن است اولویت بیشتری نسبت به همان Alert روی یک سیستم کماهمیت داشته باشد.
آیا SOC باید 24/7 باشد؟
پاسخ به این سؤال به Risk Profile سازمان بستگی دارد.
برای یک سرویس حیاتی که در تمام ساعات شبانهروز فعال است، Detection امنیتی فقط در ساعات اداری ممکن است پوشش کافی ایجاد نکند.
اما برای یک سازمان کوچک با ریسک محدود، ممکن است مدلهای On-Call، Business Hours یا Managed Monitoring منطقیتر باشند.
بنابراین بهجای اینکه «24/7 بودن» را یک ویژگی مطلق در نظر بگیریم، باید آن را بر اساس مواردی مانند:
- Criticality سرویسها
- نوع دادهها
- Risk Profile
- الزامات قانونی و قراردادی
- هزینه Incident
- RTO/RPO
- میزان Exposure به اینترنت
تعیین کنیم.
برای راهاندازی SOC از کجا شروع کنیم؟
راهاندازی SOC نباید با خرید SIEM شروع شود.
یک مسیر منطقی میتواند این مراحل را داشته باشد:
مرحله ۱: شناخت Assetها
ابتدا باید بدانید چه چیزی را قرار است محافظت کنید:
- Serverها
- Applicationها
- Databaseها
- Endpointها
- Cloud
- Kubernetes
- Identity
- Network
مرحله ۲: Risk Assessment
مشخص کنید مهمترین تهدیدها و Critical Assetهای سازمان چه هستند.
مرحله ۳: طراحی Logging
منابع مهم Log را مشخص و برای Retention، Storage، Security و Access آنها سیاست تعریف کنید.
مرحله ۴: انتخاب Technology Stack
در این مرحله ابزارهایی مانند SIEM، EDR، SOAR، IDS/IPS، WAF و Threat Intelligence انتخاب میشوند.
مرحله ۵: تعریف Use Caseها
بهجای ساخت صدها Rule بدون هدف، ابتدا Use Caseهای مهم سازمان را مشخص کنید.
برای مثال:
- Brute Force
- Privilege Escalation
- Suspicious Login
- Impossible Travel
- Malware Detection
- Data Exfiltration
- Ransomware Indicators
- Unauthorized Configuration Change
- Suspicious Kubernetes Activity
مرحله ۶: طراحی Playbook
برای Incidentهای مهم Response Procedure مشخص کنید.
مرحله ۷: ایجاد تیم
بر اساس حجم و Criticality محیط، نقشهای موردنیاز SOC را مشخص کنید.
مرحله ۸: ایجاد Metrics
از ابتدا مشخص کنید چگونه عملکرد SOC را اندازهگیری خواهید کرد.
مرحله ۹: Testing
Detectionها باید واقعاً تست شوند. Tabletop Exercise، Purple Team Exercise، Attack Simulation و سناریوهای کنترلشده میتوانند برای ارزیابی آمادگی SOC استفاده شوند.
مرحله ۱۰: Continuous Improvement
SOC یک پروژه یکباره نیست. Threatها تغییر میکنند، Infrastructure تغییر میکند، Applicationها تغییر میکنند و Detectionها نیز باید دائماً بهبود پیدا کنند.
اشتباهات رایج در راهاندازی SOC
۱. خرید SIEM و تصور اینکه SOC ساخته شده است
SIEM فقط یکی از اجزای Technology Stack است.
۲. جمعآوری همه لاگها بدون Strategy
این کار میتواند هزینه، Noise و پیچیدگی را افزایش دهد.
۳. ساخت Ruleهای زیاد بدون Tuning
Rule زیاد ولی بیکیفیت میتواند Alert Fatigue ایجاد کند.
۴. نداشتن Asset Inventory
بدون شناخت Assetها، اولویتبندی Alertها دشوار میشود.
۵. نداشتن Playbook
در زمان Incident، تصمیمگیری از صفر میتواند Response را کند کند.
۶. جدا کردن SOC از تیم زیرساخت
SOC باید با Network، Infrastructure، DevOps، Cloud، Application و IT ارتباط عملیاتی داشته باشد.
۷. تمرکز بیش از حد روی Dashboard
Dashboard زیبا جایگزین Detection Engineering و تحلیلگر متخصص نیست.
۸. اندازهگیری صرفاً بر اساس تعداد Incident
تعداد Incident بهتنهایی معیار مناسبی برای سنجش کیفیت SOC نیست.
یک SOC بالغ چه ویژگیهایی دارد؟
بلوغ SOC را بهتر است در چند بُعد بررسی کنیم:
| حوزه | SOC ابتدایی | SOC بالغ |
|---|---|---|
| Monitoring | محدود و دستی | Continuous و Centralized |
| Detection | Ruleهای عمومی | Context-aware و مبتنی بر Use Case |
| Response | دستی و وابسته به افراد | Playbook-driven و تا حدی Automated |
| Threat Hunting | محدود | فعال و مستمر |
| Automation | کم | SOAR و Workflow Automation |
| Threat Intelligence | محدود | Integrated با Detection |
| Metrics | تمرکز روی تعداد Alert | تمرکز روی Risk، Coverage و Response |
| Improvement | واکنشی | Continuous Improvement |
بلوغ واقعی فقط به تعداد ابزارها یا تعداد اعضای تیم وابسته نیست؛ بلکه به کیفیت People، Process، Technology و Governance و توانایی تبدیل دادههای امنیتی به اقدام مؤثر بستگی دارد.
SOC برای چه سازمانهایی ضروریتر است؟
هر سازمانی میتواند از قابلیتهای SOC بهره ببرد، اما اهمیت آن برای سازمانهایی که یکی از شرایط زیر را دارند بیشتر است:
- سرویسهای حیاتی و Online
- تعداد زیاد کاربر یا مشتری
- اطلاعات حساس
- زیرساخت Cloud یا Multi-Cloud
- معماری Microservices
- Kubernetes
- تعداد زیاد Endpoint
- Exposure بالا در اینترنت
- الزامات Compliance
- ریسک مالی یا عملیاتی بالا در زمان Downtime
SOC در کنار High Availability و Disaster Recovery
امنیت و Availability دو موضوع جدا از هم نیستند.
برای مثال یک Ransomware Incident ممکن است همزمان باعث Security Breach و Downtime شود. بنابراین SOC باید با تیمهای High Availability، Backup و Disaster Recovery هماهنگ باشد.
برای آشنایی بیشتر با این موضوعات میتوانید راهنماهای Disaster Recovery و تفاوت Business Continuity و Disaster Recovery را مطالعه کنید.
چکلیست راهاندازی SOC
- Asset Inventory ایجاد شده است.
- Critical Assetها مشخص شدهاند.
- Riskها شناسایی شدهاند.
- Log Sourceهای مهم مشخص شدهاند.
- Centralized Log Management وجود دارد.
- SIEM یا راهکار معادل آن انتخاب شده است.
- EDR/XDR در نقاط مناسب فعال شده است.
- Detection Use Caseها تعریف شدهاند.
- Threat Intelligence در فرآیند Detection وارد شده است.
- Incident Classification مشخص شده است.
- Playbookهای مهم نوشته شدهاند.
- Escalation Matrix مشخص است.
- مسئولیت تیمها مشخص شده است.
- SLA و زمان Response مشخص شده است.
- Threat Hunting انجام میشود.
- Detectionها بهصورت دورهای Tuning میشوند.
- Metrics و KPIهای SOC تعریف شدهاند.
- Incidentها Post-Incident Review میشوند.
- فرآیند Continuous Improvement وجود دارد.
جمعبندی؛ SOC واقعاً چیست؟
SOC یا Security Operations Center یک ابزار نیست؛ یک قابلیت عملیاتی برای دفاع مداوم از سازمان است.
یک SOC حرفهای باید بتواند دادههای امنیتی را از منابع مختلف دریافت کند، آنها را تحلیل کند، تهدیدهای مهم را شناسایی کند، Alertهای کمارزش را کاهش دهد، Incidentها را بررسی و در صورت نیاز مهار کند و از نتایج هر Incident برای بهبود سیستم دفاعی استفاده کند.
در این معماری، فناوریهایی مانند SIEM، SOAR، EDR، XDR، WAF و Threat Intelligence ابزارهای مهمی هستند؛ اما کیفیت نهایی SOC به ترکیب درست این فناوریها با نیروی انسانی متخصص، فرآیندهای مشخص، Detection Engineering، Incident Response و Continuous Improvement وابسته است.
برای سازمانهایی که زیرساختهای پیچیده، سرویسهای حیاتی، Cloud، Kubernetes یا دادههای حساس دارند، SOC میتواند یکی از لایههای اصلی استراتژی امنیت سایبری باشد.
آلتیمیت کلاد با ترکیب Security Hardening، Monitoring، Log Management، زیرساخت امن، High Availability و Disaster Recovery میتواند بخشی از این معماری را متناسب با نیاز و اندازه سازمان طراحی و پیادهسازی کند. برای بررسی معماری امنیتی زیرساخت و طراحی راهکار متناسب با سازمان، میتوانید از مشاوره تخصصی آلتیمیت کلاد استفاده کنید.
سؤالات متداول درباره SOC
SOC مخفف چیست؟
SOC مخفف Security Operations Center و به معنی مرکز عملیات امنیت است؛ واحدی که مسئول پایش، تشخیص، تحلیل و پاسخ به رخدادهای امنیتی سازمان است.
آیا SOC همان SIEM است؟
خیر. SIEM یک فناوری برای جمعآوری و تحلیل Eventهای امنیتی است، در حالی که SOC یک قابلیت عملیاتی شامل افراد، فرآیندها، فناوریها و روشهای پاسخ به تهدید است.
آیا SOC باید 24/7 باشد؟
لزومی ندارد همه سازمانها SOC 24/7 داشته باشند. میزان پوشش موردنیاز باید بر اساس Criticality سرویسها، Risk، الزامات سازمان و هزینه احتمالی Incident تعیین شود.
تفاوت SOC و CSIRT چیست؟
SOC معمولاً روی عملیات مداوم Detection، Monitoring و Analysis تمرکز دارد، در حالی که CSIRT بیشتر روی مدیریت و پاسخ تخصصی به Incidentهای امنیتی تمرکز میکند. در بعضی سازمانها این قابلیتها در یک ساختار مشترک و در برخی سازمانها بهصورت تیمهای جداگانه فعالیت میکنند.
آیا سازمان کوچک هم به SOC نیاز دارد؟
سازمان کوچک الزاماً به یک SOC بزرگ و چندشیفته نیاز ندارد، اما میتواند بر اساس Risk خود از قابلیتهایی مانند Centralized Logging، Monitoring، EDR، Alerting، Incident Response و Managed SOC استفاده کند.
آیا داشتن Firewall به معنی داشتن SOC است؟
خیر. Firewall یکی از کنترلهای امنیتی است. SOC وظیفه دارد اطلاعات حاصل از کنترلهای مختلف را در یک فرآیند عملیاتی برای Detection و Response به کار بگیرد.
آیا SOC فقط برای تشخیص حمله است؟
خیر. SOC علاوه بر Detection، فعالیتهایی مانند Triage، Investigation، Threat Hunting، Incident Response، Detection Engineering، Threat Intelligence، Reporting و Continuous Improvement را نیز پوشش میدهد.
