مقدمه‌ای بر عملیات SIEM: راهنمای عملی تیم Blue

پلتفرم‌های Security Information and Event Management (SIEM) در قلب اکثر Security Operations Centers (SOCs) قرار دارند. آنها log‌ها را جمع می‌کنند، رویدادها را تطابق می‌دهند، و alert‌هایی را به سطح می‌رسانند که تحلیلگران باید آنها را triage و تحقیق کنند. این راهنما از workflow عملیاتی اصلی عبور می‌کند تا بتوانید مانند یک تحلیلگر SIEM فکر کنید، صرف نظر از اینکه سازمان شما از کدام پلتفرم (Splunk، Elastic، Microsoft Sentinel، QRadar و غیره) استفاده می‌کند.

SIEM در واقع چه کاری انجام می‌دهد

در هسته خود، SIEM سه کار را انجام می‌دهد: جمع‌آوری log از endpoints، دستگاه‌های شبکه، برنامه‌ها و cloud services؛ نرمال‌سازی آن داده‌ها به یک schema یکسان؛ و تطابق رویدادها با استفاده از detection rules برای تولید alert. تحلیلگران سپس آن alert‌ها را از یک triage و investigation lifecycle عبور می‌دهند. درک این pipeline به شما کمک می‌کند تا مشکلات را تشخیص دهید وقتی داده‌ها نادرست به نظر می‌رسند یا alert‌ها مفقود به نظر می‌آیند.

راه‌اندازی Log Sources

قبل از اینکه هیچ detection logic مهم باشد، به داده‌های قابل اعتماد نیاز دارید. منابع معمول شامل موارد زیر است:

• Endpoint telemetry (EDR agents، Windows Event Logs از طریق Sysmon)
• Network data (firewall logs، DNS queries، proxy logs، NetFlow)
• Authentication logs (Active Directory، VPN، SSO providers)
• Cloud audit logs (AWS CloudTrail، Azure Activity Logs، GCP Audit Logs)

هنگام onboarding یک منبع جدید، دقت timestamp را تحقق کنید، تأیید کنید که field parsing صحیح است، و ingestion volume را بر اساس baselines مورد انتظار بررسی کنید. یک parser نادرست‌پیکر به طور خاموش detections را شکست می‌دهد بدون اینکه error بردارد، بنابراین به طور منظم raw events را بر اساس parsed fields بررسی کنید.

نوشتن و Tuning Detection Rules

اکثر SIEMs از نوع correlation search یا detection rule syntax استفاده می‌کنند. یک مثال ساده در SPL Splunk می‌تواند به این صورت باشد:

index=auth sourcetype=windows EventCode=4625
| stats count by user, src_ip
| where count > 10

این account‌هایی را که بیش از 10 تلاش login ناموفق دارند flag می‌کند، یک indicator brute-force کلاسیک. هنگام ساخت rules:

1. از یک دامنه محدود شروع کنید، سپس بر اساس false positive rate گسترش دهید.
2. هر rule را به یک MITRE ATT&CK technique نگاشت کنید برای context و coverage tracking.
3. intent rule، expected data source، و known false-positive scenarios را مستند کنید.
4. threshold‌های واقع‌گرایانه تعیین کنید — خیلی حساس و تحلیلگران در noise غرق می‌شوند؛ خیلی loose و تهدیدات واقعی فرار می‌کنند.

Alert Triage Workflow

پس از اینکه یک alert fire شود، کار تحلیلگر این است که پاسخ دهد: آیا این malicious است و آیا نیاز به escalation دارد؟ یک practical triage checklist:

• Validate the alert — تأیید کنید که underlying event واقعاً رخ داده و parsing artifact نیست.
• Enrich with context — asset criticality، user role، geolocation source IP، و recent related alerts را روی host یکسان بررسی کنید.
• Check for a pattern — روی user، IP، یا hash را در یک time window گسترده‌تر pivot کنید تا ببینید آیا این isolated است یا بخش یک broader campaign.
• Classify — true positive، false positive، یا benign true positive (real activity، اما نه malicious، مثل یک script legitimate یک admin).
• Escalate or close — reasoning خود را به هر دو روش document کنید؛ closed alerts همچنان به یک clear justification برای audit purposes نیاز دارند.

ساخت Effective Dashboards

Dashboards باید specific operational questions را پاسخ دهند، نه فقط impressive به نظر بیایند. مثال‌های مفید شامل موارد زیر است:

• Top failed authentication sources در 24 ساعت گذشته
• Alert volume بر اساس severity و analyst assignment
• Data source health (ingestion lag، drop-offs)
• Detection coverage mapped بر اساس ATT&CK tactics

از dashboard sprawl اجتناب کنید — چند high-signal views بهتر از بیست rarely-checked panels است.

Handling False Positive Fatigue

Alert fatigue یکی از بزرگ‌ترین operational risks در یک SOC است. با موارد زیر با آن مقابله کنید:

• به طور منظم closed alerts را review کنید تا recurring false-positive patterns را شناسایی کنید.
• known-benign activity را با documented exceptions suppress کنید (نه blanket rule disabling).
• mean time to triage و mean time to respond را به عنوان metrics track کنید تا bottlenecks را detect کنید.
• detection rule review cycles را rotate کنید تا stale، noisy rules refined یا retired شوند.

Documentation و Handoff

هر investigation باید یک paper trail بگذارد: چه چیزی alert را trigger کرد، چه چیزی را check کردید، چه نتیجه‌ای به دست آمد، و هر گونه follow-up actions. این برای shift handoffs، compliance audits، و ساخت institutional knowledge که analyst turnover را survive کند مهم است. یک simple runbook template برای هر alert type — investigation steps، escalation contacts، و expected evidence — زمان قابل توجهی را تحت فشار صرفه‌جویی می‌کند.

Getting Hands-On Practice

سریع‌ترین راه برای ساخت SIEM fluency تکرار است: sample logs را ingest کنید، یک handful detection rules را بر اساس known attack techniques بنویسید، و full triage cycle را end to end practice کنید. Free datasets و open-source SIEM stacks (مثل Elastic Stack) environments ممتازی با cost پایین برای این کار هستند.

آیا برای رفتن عمیق‌تر به blue team fundamentals آماده‌اید؟ Korra Studio segments را روی log analysis، incident response workflows، و detection engineering explore کنید تا ادامه دهید SOC skill set خود را بسازید.