Log360
یکی از پرهزینه‌ترین اشتباه‌های SIEM این است که همه Logها را با یک سیاست نگهداری یکسان ذخیره کنیم. Log احراز هویت Domain Controller، Audit یک Firewall، رویداد Debug یک Application و Telemetry کم‌ارزش الزاماً نباید مدت و سطح دسترسی یکسان داشته باشند.
Log Retention در Log360 باید از Risk و Use Case شروع شود: کدام Log برای Detection سریع لازم است؟ کدام Log فقط برای Forensics یا Compliance باید بماند؟ و چه داده‌ای بعد از مدت مشخص دیگر ارزش نگهداری ندارد؟
Search Storage و Archive چه تفاوتی دارند؟
در Log360 Cloud، ManageEngine امکان تفکیک Search Storage و Archival Storage را ارائه می‌کند. ایده ساده است: Logهای موردنیاز برای جست‌وجوی روزمره و Detection در لایه Search می‌مانند؛ داده‌هایی که کمتر استفاده می‌شوند اما برای Investigation یا Compliance باید حفظ شوند، می‌توانند به Archive بروند.
| لایه | کاربرد | نمونه داده |
|---|---|---|
| Search Storage | جست‌وجوی سریع و تحلیل جاری | Authentication، Firewall، EDR |
| Archive | نگهداری بلندمدت و Forensics | Audit تاریخی، Log الزامی |
Retention را بر اساس Log Type طراحی کنید
یک Policy واحد مانند «همه Logها یک سال» معمولاً هم گران است و هم غیرهوشمند. بهتر است Data Sourceها را طبقه‌بندی کنید:
- Identity و Privileged Access؛
- Security Deviceها؛
- Server و Operating System؛
- Cloud Audit؛
- Application Log؛
- Database Audit؛
- Diagnostic و Debug Log.
سپس برای هر گروه Search Retention، Archive Retention و Owner تعیین کنید.
سناریو: Incident بعد از سه ماه کشف می‌شود
فرض کنید IOC جدیدی نشان می‌دهد نفوذ احتمالی ۹۰ روز قبل رخ داده است. اگر Raw Log همان دوره Purge شده باشد، تیم SOC دیگر نمی‌تواند Timeline را بازسازی کند. از طرف دیگر نگهداری تمام Debug Logها در Search Tier برای ۳۶۵ روز نیز می‌تواند هزینه غیرضروری ایجاد کند.
Archive باید قابل بازگشت به Investigation باشد
در Log360 Cloud امکان Reload Archive Logs برای جست‌وجوی داده آرشیوی پیش‌بینی شده است. این نکته مهم است، چون Archive نباید قبرستان داده باشد؛ در رخداد باید بتوان داده لازم را دوباره وارد مسیر Investigation کرد.
Compliance فقط تعداد روز نیست
بعضی مقررات حداقل دوره نگهداری Log تعیین می‌کنند، اما Compliance واقعی به Integrity، دسترسی کنترل‌شده، زمان‌بندی، Audit Trail و قابلیت ارائه شواهد هم مربوط است. Logی که یک سال نگهداری شده ولی قابل اعتماد یا قابل بازیابی نیست، Evidence ضعیفی است.
چطور هزینه SIEM را کنترل کنیم؟
| روش | اثر |
|---|---|
| طبقه‌بندی Sourceها | جلوگیری از Retention یکسان |
| فیلتر Noise | کاهش حجم بدون حذف Event مهم |
| Search کوتاه‌تر برای داده کم‌ارزش | کاهش هزینه لایه سریع |
| Archive برای Evidence بلندمدت | تعادل هزینه و Compliance |
| بازبینی دوره‌ای Policy | هماهنگی با Risk و Regulation |
Retention را به Detection Engineering وصل کنید
اگر Correlation Rule شما برای تشخیص یک حمله به ۳۰ روز Historical Data نیاز دارد، نباید Source مرتبط بعد از ۷ روز از Search خارج شود. مقاله Correlation Rule در Log360 کمک می‌کند Retention را با Detection واقعی هماهنگ کنید.
Cloud Logها را فراموش نکنید
در محیط Hybrid، داده AWS، Azure و Microsoft 365 بخشی از Timeline Incident است. برای معماری جمع‌آوری این داده‌ها می‌توانید راهنمای Cloud SIEM با Log360 را ببینید.
منابع رسمی
سخن پایانی
Log Retention خوب یعنی داده مناسب، در Tier مناسب، برای مدت مناسب. هدف نگهداری بیشترین حجم ممکن نیست؛ هدف این است که SOC هنگام Detection و Forensics داده لازم را داشته باشد و سازمان برای Compliance نیز Evidence قابل دفاع نگه دارد.
مدانت خدمات لایسنس، طراحی SIEM، استقرار، تنظیم Log Source، Correlation، Retention و پشتیبانی Log360 ارائه می‌کند. برای بررسی راهکار به Log360 در مدانت مراجعه کنید.
