پیاده‌سازی SIEM برای وب‌سایت؛ Log، Detection و Incident

اگر SIEM شما روزانه ده‌هزار هشدار می‌سازد اما هنگام تصاحب حساب مدیر نمی‌تواند بگوید «چه کسی، با کدام Session، چه داده‌ای را تغییر داد»، Log بیشتری لازم ندارید؛ Detection design بهتری لازم دارید. جمع‌کردن همه رویدادها بدون سؤال امنیتی، Owner، Runbook و Retention فقط هزینه و خستگی هشدار تولید می‌کند.

این راهنما SIEM را برای وب‌سایت و وب‌اپلیکیشن به‌صورت عملی پیاده می‌کند: از Fit و Detection objective تا Log schema، Privacy، Pipeline، Use case، Rule-as-code، Triage، Incident response، SOAR، TCO و پایلوت. مثال‌ها برای فروشگاه، SaaS، پنل مدیر و API نوشته شده‌اند و محدودیت تیم، پرداخت، دسترسی SaaS خارجی و شبکه ایران را در تصمیم وارد می‌کنند.

SIEM چیست؟

SIEM یا Security Information and Event Management، Telemetry امنیتی را از چند منبع جمع، Parse، Normalize، غنی و Correlate می‌کند تا Detection، Investigation، گزارش و پاسخ پشتیبانی شوند. ارزش آن در Dashboard متمرکز نیست؛ در کاهش زمان رسیدن از Signal به تصمیم معتبر است.

NIST SP 800-92 برای مدیریت Log سازمانی، زیرساخت و فرایند پایدار را محور می‌داند. این سند قدیمی است، اما اصول Scope، Collection، Storage، Analysis و Operations آن همچنان برای طراحی پایه مفید است؛ جزئیات فناوری را باید با Architecture امروز تطبیق داد.

SIEM با ابزارهای دیگر چه تفاوتی دارد؟

SIEM ابزار اصلی بهینه‌سازی سرعت سایت نیست. Log آن می‌تواند خطای ۵xx یا الگوی Timeout را به Incident امنیتی مرتبط کند، اما LCP، INP، Trace و SLO معمولاً در Observability/APM بهتر مدیریت می‌شوند. مرز داده و دسترسی این دو سامانه را روشن نگه دارید.

آیا هر وب‌سایتی به SIEM نیاز دارد؟

خیر. یک سایت محتوایی کوچک بدون Login یا داده حساس ممکن است با Logging ساختاریافته، Alertهای Hosting/WAF، Backup و پاسخ Incident ساده شروع کند. SIEM زمانی ارزش بیشتری دارد که چند Source، هویت/تراکنش حساس، نیاز Investigation، حجم رویداد، تیم On-call یا الزام Evidence وجود دارد.

بودجه را بر Risk و Coverage اولویت‌بندی کنید؛ راهنمای بودجه امنیت سایت کمک می‌کند SIEM را با کنترل‌های پیشگیرانه، Recovery و People مقایسه کنید.

از Detection Objective شروع کنید

قبل از Connector، سناریوهای قابل‌تصمیم بنویسید: چه رفتار یا اثر نامطلوبی، روی کدام دارایی، با چه Signalهایی و چه Actionی باید کشف شود؟ «تشخیص حمله» قابل تست نیست.

Risk: تصاحب حساب مدیر
Behavior: login جدید → MFA reset → role change → bulk export
Required telemetry: IdP + app auth + admin audit + data export
Detection: sequence by actor/session/account within time window
Response: revoke session, freeze export, preserve evidence, page owner
Success: scenario detected with correct context before material loss

MITRE ATT&CK زبان مشترکی برای رفتار مهاجم می‌دهد؛ صفحه رسمی Detection and Analytics بر ساخت و اصلاح Analytics مبتنی بر Technique تأکید می‌کند. ATT&CK را Checklist پوشش صددرصدی نکنید؛ Threat model و دارایی خودتان تعیین‌کننده‌اند.

Telemetry map وب‌سایت را بسازید

Application log معمولاً Context گمشده را دارد

وب‌سرور می‌داند درخواست ۲۰۰ شد؛ اپلیکیشن می‌داند چه Userی با چه Roleی کدام سفارش یا داده را Export کرد. OWASP Logging Cheat Sheet تأکید می‌کند Application logging فراتر از فعال‌کردن Web-server log است و باید Context کافی برای Monitoring و Investigation داشته باشد.

قرارداد رویداد استاندارد بسازید

event_id, event_time, observed_time
service, environment, version, host/workload
actor_id, actor_type, role, session_hash
source_ip, user_agent/device, geo_confidence
action, object_type, object_id_hash
outcome, reason_code, severity
trace_id, request_id, correlation_id
data_class, source, schema_version

نام فیلد، Type، Enum، Timezone، Null و Version را Contract کنید. Event producer باید Test داشته باشد و Breaking change بدون هماهنگی Ruleها منتشر نشود. Identity و Object را بین Sourceها Resolve کنید، اما Confidence و منبع را حفظ کنید؛ Geo-IP یا User-agent حقیقت قطعی نیست.

زمان و Correlation را جدی بگیرید

هم Event time و هم Ingest/Observed time را نگه دارید. Clockها را تا حد ممکن Sync و Offset/Confidence را ثبت کنید. Mobile، Edge یا سیستم Offline ممکن است دیر ارسال کند؛ Sort بر اساس زمان ورود، Timeline حادثه را تحریف می‌کند.

چه چیزهایی را نباید Log کرد؟

Password، Access/refresh token، Session ID خام، Encryption key، Connection string، Payment/card data، کد ملی، شماره شبا، Health data و Request/response body کامل را پیش‌فرض Log نکنید. Purpose Investigation را با Data minimization، Mask/Hash/Tokenization و Access کنترل‌شده متعادل کنید.

OWASP هشدار می‌دهد Log می‌تواند خود حاوی داده حساس باشد. Hash نیز همیشه ناشناس‌سازی قطعی نیست؛ Salt/Key، امکان Linkage و Threat model اهمیت دارند. Data map، Retention و انتقال به SaaS را با Owner حریم خصوصی/حقوقی بررسی کنید.

Log injection و payload مخرب

Event ورودی از Trust zone دیگر را Untrusted بدانید. Schema validation، طول، Encoding و حذف CR/LF/Delimiter خطرناک لازم است. Dashboard نباید محتوای Log را به‌صورت HTML اجرا کند و Parser failure نباید کل Pipeline را متوقف سازد.

Pipeline باید Failure را تحمل کند

producer → local buffer/agent → secure transport → queue
→ parse/validate → enrich/normalize → hot search
→ detection → case/ticket → archive

Backpressure، Disk full، Network outage، Retry، Duplicate، Out-of-order، Drop و Poison event را طراحی کنید. Logging failure نباید اپلیکیشن را بی‌جهت Down کند یا داده حساس را به کاربر نشت دهد؛ در عین حال باید Sensor health و Gap دیده شود.

Log را در انتقال و نگهداری محافظت کنید

TLS/mTLS یا کانال امن، Authentication Source، Least privilege، جداسازی Write/Read/Admin، Encryption at rest، Audit دسترسی و Tamper-evidence لازم‌اند. مهاجم ممکن است برای پوشاندن ردپا Logging را خاموش یا Archive را حذف کند؛ Health alert و Copy خارج از Failure domain بسازید.

Source، Collector، Queue و SIEM نیز Supply chain دارند. Update، Secret، Plugin/Parser، Tenant isolation و Export/Exit Provider را در ارزیابی امنیت ابری با چک‌لیست هاست ابری امن بسنجید.

Retention را بر سؤال تحقیق طراحی کنید

«همه Logها یک سال» هم گران است هم ممکن است بی‌دلیل داده حساس نگه دارد. برای هر Event class، Detection latency، Investigation window، الزام قابل اعمال، ارزش Evidence، حجم، دسترسی و Delete را تعیین کنید.

Sampling برای Event امنیتی حیاتی می‌تواند Evidence را نابود کند. ابتدا Eventهای پرحجم کم‌ارزش، Debug noise یا فیلد زائد را کاهش دهید؛ Drop rule باید Owner، Reason، Expiry و Test داشته باشد.

Use caseها را بر Risk و Prerequisite اولویت دهید

1. Credential stuffing و Password spray؛
2. ورود موفق پس از شکست‌های غیرعادی؛
3. MFA reset، Token creation و Session anomaly؛
4. افزایش Role یا استفاده Break-glass؛
5. تغییر WAF/IAM/Firewall/Logging/Backup؛
6. Bulk export یا دسترسی داده خارج Baseline؛
7. API rate/business-flow abuse؛
8. Deploy/Artifact/Secret غیرمنتظره.

برای Credential stuffing و Botهای پیشرفته، راهنمای مدیریت ربات مخرب Signal→Action و False-positive را باز می‌کند. WAF فقط یک Source/Enforcement است؛ برای تنظیم Rule و Rollout امن به راهنمای WAF Tuning مراجعه کنید.

Detection-as-Code و Lifecycle Rule

Rule باید Version، Owner، Hypothesis، Risk/Technique، Data prerequisite، Query، Threshold، Severity، Enrichment، Response، Test fixture، Known false positive، Exception و Review date داشته باشد.

idea → design → sample/backtest → peer review → staging
→ shadow → limited alert → production → tune
→ validate continuously → improve or retire

Rule کپی‌شده از Vendor ممکن است Field/Identity/Business context شما را نداشته باشد. «Best practice» را به Dataset خود Backtest و سپس با Simulation مجاز Validate کنید.

نمونه Detection: تصاحب حساب

Correlation بر Actor/Session/Account/Device و زمان، داستان معتبرتری می‌سازد. Response باید بین «مشکوک» و «تأییدشده» فرق بگذارد تا مهاجم با ساخت Signal جعلی موجب قفل گسترده کاربران نشود.

API و Business logic را فقط با Status code نبینید

برای API، Client/workload identity، Route template، Method، Auth result، Policy decision، Object، Rate bucket، Idempotency key، outcome و latency را ثبت کنید؛ Query string/Body حساس را Mask کنید. Sequence غیرمجاز—مثلاً Refund قبل از Settlement—ممکن است با کد ۲۰۰ اجرا شود.

راهنمای امن‌سازی API Access contract، تست منفی و Business-flow abuse را برای تولید Event و Detection درست پوشش می‌دهد.

Alert باید Case قابل رسیدگی بسازد

هشدار خوب فقط نام Rule و IP ندارد. «چه شد، چرا مهم است، Confidence چیست، چه دارایی/هویتی درگیر است، Timeline و Evidence کجاست و اقدام بعدی چیست» را ارائه می‌دهد.

Alert → dedupe/suppress → enrich → risk score
→ owner/queue → triage → case → contain/escalate/close
→ disposition → feedback to rule and control

Severity را با Business impact ترکیب کنید

یک Signal یکسان روی محیط Test و Database مشتری Severity متفاوت دارد. Asset criticality، Data class، Privilege، Blast radius، Confidence و کنترل جبرانی را وارد کنید. ML anomaly بدون توضیح و Response نیز فقط یک Signal است.

Runbook و Authority را پیش از Alert بنویسید

Analyst باید بداند چه Query اجرا کند، چه Evidence حفظ شود، با چه کسی تماس بگیرد و چه اقدامی بدون Approval مجاز است. Revoke session ممکن است کم‌خطر باشد؛ حذف Data یا Block گسترده IP می‌تواند کسب‌وکار را متوقف کند.

NIST SP 800-61 Rev. 3 Incident response را در کل Cyber risk management و CSF ۲.۰ ادغام می‌کند. SIEM بدون آماده‌سازی، ارتباط، Recovery و Lessons learned پاسخ کامل نیست.

SOAR را با Guardrail خودکار کنید

هر Playbook باید Dry-run، Idempotency، Timeout، Error path، Audit و Rollback داشته باشد. Automation سریعِ Rule ضعیف، Incident را بزرگ‌تر می‌کند.

کیفیت Detection را با Funnel بسنجید

«False positive rate» بدون Label و Denominator دقیق می‌تواند گمراه‌کننده باشد. Disposition taxonomy و نمونه‌برداری از Alertهای Suppressed/No-alert لازم است تا Blind spot را نبینیم. MTTD/MTTR میانگین نیز Tail حادثه‌های بحرانی را پنهان می‌کند.

Detection را با Simulation مجاز اعتبارسنجی کنید

Unit test برای Parser/Rule، Replay رویداد مصنوعی، Backtest، Purple-team exercise و Pen-test مجاز کمک می‌کنند بدانید Signal تولید و Alert تحویل می‌شود. تست نفوذ فقط Finding نیست؛ باید Detection و Response را نیز بسنجد. Scope و Rules of Engagement را با راهنمای تست نفوذ وب‌اپلیکیشن تنظیم کنید.

Compliance report جای امنیت را نمی‌گیرد

SIEM می‌تواند Evidence و Report بسازد، اما انطباق به Scope، Control design، operation و قانون قابل اعمال وابسته است. جمع‌آوری بیش‌ازحد Log حتی می‌تواند Privacy risk ایجاد کند. Retention و دسترسی را با متخصص همان حوزه تأیید کنید.

Build، Buy، Open-source یا MSSP؟

نام یا قیمت جاری ابزارها سریع تغییر می‌کند؛ این مقاله رتبه‌بندی Vendor ارائه نمی‌دهد. با Dataset و Use case نماینده، Query latency، Parser، Rule، Case، API/export، Support، TCO و Exit را Pilot کنید.

TCO واقعی SIEM را حساب کنید

SIEM TCO
= ingest + hot/warm/archive + query/compute + egress
+ connector/parser + detection content + SOAR/integration
+ analyst/on-call + tuning + threat research + training
+ audit/privacy + incident reserve + migration/exit

EPS یا GB/day به‌تنهایی هزینه را توضیح نمی‌دهد؛ Burst، Compression، Indexing، Enrichment، Query، Retention، Rehydration و Duplicate مهم‌اند. هزینه نقض و Downtime را نیز به Range بسنجید؛ راهنمای هزینه نقض داده برای BIA و Residual risk مفید است.

واقعیت عملیاتی ایران

دسترسی SaaS، حساب و پرداخت

Eligibility کشور/سازمان، KYC، روش پرداخت، Renewal، Support و ریسک Suspension را از منبع رسمی Provider و قرارداد بررسی کنید. راهکار متکی بر حساب یا پرداخت شکننده، در Incident بحرانی خطرناک‌تر است. Export و Recovery window را پیش از ورود تست کنید.

شبکه و ارسال Telemetry

Collector باید Buffer، Backpressure، Retry با Idempotency و Health monitoring داشته باشد. مسیر ارسال را از چند ISP و Site آزمایش کنید و تعیین کنید در قطع ارتباط چه داده‌ای محلی می‌ماند، چه زمانی Drop می‌شود و پس از اتصال چگونه Replay/Reconcile می‌شود.

زمان، زبان و کانال On-call

Event time را UTC و نمایش را با منطقه زمانی تهران قابل تبدیل نگه دارید؛ ساعت سیستم و تغییر دستی را Audit کنید. Dashboard/Runbook فارسی می‌تواند سرعت تیم محلی را بالا ببرد، اما Field name و Enum استاندارد بمانند. Paging فقط به SMS یا یک پیام‌رسان متکی نباشد؛ Channel جایگزین و Escalation tree آفلاین داشته باشید.

داده حساس و محل نگهداری

انتقال Log حاوی PII، IP، رفتار کاربر یا Secret به Provider بیرونی نیاز Data map، Minimization، Contract و بررسی حقوقی دارد. Mask را نزدیک Source انجام دهید و Dataset Test را از داده واقعی جدا کنید.

نقشه راه ۹۰روزه SIEM

1. روز ۱ تا ۱۵: BIA/Threat، پنج Use case، Owner/Runbook و Data/privacy contract.
2. روز ۱۶ تا ۳۰: دو Source حیاتی، Event schema، secure pipeline و Sensor health.
3. روز ۳۱ تا ۴۵: سه Rule-as-code، Backtest، Case enrichment و Triage؛ تغییر Rule را وارد Review و Pipeline کنید و از الگوی یکپارچه‌سازی امنیت در DevOps برای Test و Release کنترل‌شده کمک بگیرید.
4. روز ۴۶ تا ۶۰: Simulation/Tabletop، Incident handoff و Restore evidence.
5. روز ۶۱ تا ۷۵: Cost/retention/tier tuning و پنج Use case بعدی.
6. روز ۷۶ تا ۹۰: Coverage/Funnel/TCO/Gap و تصمیم Scale/Hold/Stop.

اولین Slice بهتر است یک Journey پرریسک مثل Login→MFA reset→Admin action→Export باشد. ده‌ها Connector بدون Detection قابل تست، پیشرفت نیست.

اشتباه‌های رایج پیاده‌سازی SIEM

• جمع‌آوری همه‌چیز: از سؤال Detection و Retention شروع کنید.
• وب‌سرور به‌جای App context: Authorization و Business event بسازید.
• Logکردن Secret/PII: Minimize، Mask و کنترل دسترسی کنید.
• Rule Vendor بدون تست: Schema/Threat/Base rate خودتان را اعتبارسنجی کنید.
• Alert بدون Owner/Runbook: پیش از Production مسیر رسیدگی بسازید.
• اتوماسیون Block گسترده: Approval، TTL و Rollback قرار دهید.
• Compliance dashboard = امنیت: Detection/Response outcome را بسنجید.
• Open source = رایگان: People، عملیات، Storage و Exit را در TCO بیاورید.

چک‌لیست نهایی

• Risk/Threat/Asset به Detection objective و Response وصل است.
• هر Source دلیل، Owner، Schema، Health و Retention دارد.
• Application eventهای هویت، مجوز، Admin، Export و Workflow را پوشش می‌دهد.
• Secret/Token/PII/Payment data پیش از ارسال حذف یا محافظت می‌شوند.
• Time، Identity، Correlation و Schema version استانداردند.
• Pipeline در Outage/Backpressure/Poison/Drop تست شده است.
• Log در Transit/At rest و برابر Tamper/Deletion محافظت می‌شود.
• Rule version/owner/test/FP/exception/review date دارد.
• Alert Context، Severity، Case، Runbook و Authority دارد.
• SOAR Dry-run، Idempotency، Guardrail و Rollback دارد.
• Detection با Replay/Simulation/Purple team اعتبارسنجی شده است.
• Telemetry/Detection/Operations/Response/Business Funnel و TCO گزارش می‌شوند.

جمع‌بندی: SIEM زمانی امنیت می‌سازد که هر بایت Log به یک سؤال، هر Alert به یک تصمیم و هر تصمیم به یک Runbook متصل باشد. از پنج Use case پرریسک و Telemetry قابل اعتماد شروع کنید؛ داده حساس را کمینه کنید، Detection را مثل کد تست کنید و پیش از Scale نشان دهید تیم واقعاً می‌تواند حادثه را کشف، مهار و بازیابی کند.

پرسش‌های متداول

SIEM به زبان ساده چیست؟

سامانه‌ای است که رویدادهای امنیتی چند منبع را جمع و یکدست می‌کند، آن‌ها را برای کشف رفتار مشکوک Correlate می‌کند و Evidence لازم برای Triage و Incident response می‌دهد. SIEM بدون Rule، Analyst و Runbook فقط مخزن Log است.

آیا وب‌سایت کوچک به SIEM نیاز دارد؟

نه همیشه. سایت کم‌ریسک می‌تواند با Log مرکزی، چند Alert حیاتی و Runbook شروع کند. اگر Login/داده حساس، چند Source، نیاز Investigation یا On-call دارید، SIEM یا Managed detection ارزش بیشتری پیدا می‌کند.

اولویت Logها برای SIEM وب‌سایت چیست؟

از Use case بیایید: معمولاً IdP/Auth، Application authorization/admin/export، API gateway، WAF/CDN و Cloud control plane بیشترین Context اولیه را می‌دهند. Database/host/CI-CD/backup را بر Threat و Architecture اضافه کنید.

تفاوت SIEM و WAF چیست؟

WAF درخواست وب را در Edge بررسی و Allow/Block می‌کند؛ SIEM رویدادهای WAF را همراه هویت، اپلیکیشن، Cloud و Database تحلیل می‌کند. WAF یک Sensor/Enforcement point است و SIEM لایه Correlation/Investigation؛ جای هم را نمی‌گیرند.

بهترین SIEM کدام است؟

پاسخ عمومی ندارد. Data volume، Use case، Skill، Residency، Parser، Rule/Case، API، Support، TCO و Exit تعیین‌کننده‌اند. با Dataset و سناریوی نماینده SaaS، Self-host، Open-source یا MSSP را در Pilot مقایسه کنید.