بخش ۵ — چالش‌های عملیاتی و حریم خصوصی: آنچه بین تئوری و واقعیت فاصله می‌اندازد
بخش قبل سامانهٔ SIEM را به‌عنوان مغز تحلیلی معرفی کرد. SIEM روی کاغذ و SIEM در عمل دو سیستم متفاوت‌اند و فاصلهٔ میان همین دو، جایی است که این پروژه‌ها شکست می‌خورند. این بخش دربارهٔ همین فاصله است: چالش‌هایی که تنها پس از رسیدن ترافیک واقعی، مهاجم واقعی و صورتحساب واقعی خودشان را نشان می‌دهند.
پنج چالش بنیادین وجود دارد که هر معمار لاگ مرکزی دیر یا زود با آن‌ها روبه‌رو می‌شود: هزینه و حجم داده، کیفیت داده، امنیت خود سیستم لاگ، حریم خصوصی و انطباق، و زمان. چالش ششم در انتهای همین بخش مطرح می‌شود و کمتر دربارهٔ آن گفته شده است: نیروی انسانی و تنظیم مستمر. هیچ‌کدام از این‌ها در بروشور فروشندگان ابزار برجسته نمی‌شوند، ولی همهٔ آن‌ها تعیین‌کنندهٔ موفقیت یا شکست یک پروژهٔ لاگ مرکزی هستند.
حجم داده و هزینهٔ ذخیره‌سازی
نخستین چالش همان چالش ساده است: لاگ‌ها رشد می‌کنند. یک شبکهٔ متوسط روزانه از چند صد گیگابایت تا چند ترابایت لاگ تولید می‌کند. نگه داشتن همهٔ این داده برای یک سال، هزینه‌ای دارد که بیشتر سازمان‌ها پیش‌بینی نمی‌کنند.
این هزینه فقط دربارهٔ ذخیره‌سازی خام نیست. ذخیره‌سازی ایندکس‌محور مانند Elasticsearch از نگه داشتن یک فایل ساده گران‌تر است، چون ایندکس برای جست‌وجوی سریع ساخته شده است. اگر همهٔ رکوردها در فاز Hot روی SSD سریع بمانند، هزینه با حجم داده به‌شدت بالا می‌رود.
به همین دلیل، معماری‌های بالغ از چرخهٔ عمر داده استفاده می‌کنند. داده‌های تازه در فاز Hot می‌مانند، داده‌های قدیمی‌تر به Warm و Cold منتقل می‌شوند و در نهایت به Frozen می‌روند که همان آبجکت استوریج ارزان است.
طراحی این چرخهٔ عمر، تصمیمی اقتصادی و حقوقی است، نه فقط فنی. استاندارد PCI-DSS صریحاً الزام می‌کند که لاگ‌ها حداقل ۱۲ ماه نگه داشته شوند و دست‌کم ۳ ماه اخیر «فوراً در دسترس» باشند. یعنی نمی‌توانید همه‌چیز را بعد از یک ماه حذف کنید، و نگه داشتن همه‌چیز برای همیشه پایانی ندارد.
پاسخ عملی، پنجرهٔ نگهداری مبتنی بر ریسک است: داده‌های اخیر سریع و قابل جست‌وجو می‌مانند، داده‌های قدیمی‌تر به آرشیو می‌روند و داده‌هایی که هیچ الزام قانونی یا عملیاتی برای نگه داشتنشان نیست حذف می‌شوند.
یک مطالعهٔ دانشگاهی نشان داد که کمتر از ۵ درصد رکوردهای قدیمی‌تر از ۹۰ روز هرگز پرس‌وجو نمی‌شوند. بخش عمدهٔ آنچه نگه می‌دارید در عمل استفاده نمی‌شود، ولی همان ۵ درصد دقیقاً وقتی یک تحقیق به سراغش می‌آید حیاتی می‌شود.
قبل از خرید هر ابزاری به یک پرسش پاسخ دهید: چه چیزی را چقدر نگه می‌داریم و چرا؟ اگر پاسخ روشنی ندارید، صورتحساب ذخیره‌سازی شما تا مرزی می‌رود که هیچ‌کس در پروژه نمی‌تواند به آن اشاره کند.
کیفیت داده
چالش دوم ظریف‌تر است و معمولاً دیر کشف می‌شود: داده‌ای که دارید، ممکن است آن چیزی نباشد که فکر می‌کنید. سه شکل متفاوت از این مشکل در عمل دیده می‌شود.
منابع خاموش. یک فایروال، یک سرور یا یک برنامهٔ حیاتی ممکن است به‌دلیل خطای پیکربندی لاگ نفرستد. سیستم مرکزی هیچ هشداری نمی‌دهد، چون از نظر فنی همه‌چیز کار می‌کند و فقط داده نمی‌رسد.
مرکز امنیت سایبری کانادا تأکید می‌کند سازمان‌ها به‌طور منظم بررسی کنند که آیا همهٔ منابع حیاتی واقعاً لاگ می‌فرستند یا نه، چون یک منبع خاموش، یک حفرهٔ امنیتی نامرئی است. پاسخ، پایش سلامت منبع است: برای هر منبع حیاتی یک آستانهٔ زمانی تعریف کنید و وقتی چیزی نرسید هشدار بدهید.
یک آستانهٔ عملی این‌گونه است: اگر از یک سرور مشخص در ۱۰ دقیقهٔ گذشته هیچ لاگی نیامد، هشدار بدهید. سلامت منبع باید پیوسته پایش شود، نه اینکه یک‌بار هنگام نصب بررسی شود.
قالب‌های شکسته. یک برنامه ممکن است نسخهٔ جدیدی منتشر کند که قالب لاگش را تغییر می‌دهد. وقتی قاعدهٔ تجزیه با چیدمان جدید هماهنگ نباشد، فیلدها استخراج نمی‌شوند و لاگ به شکل متن خام باقی می‌ماند. سامانهٔ SIEM رکورد را می‌بیند ولی نمی‌تواند آن را تحلیل کند.
نرخ موفقیت تجزیه را پایش کنید، یعنی سهم لاگ‌هایی که فیلدهایشان درست استخراج می‌شود. وقتی این درصد کاهش پیدا کند، برنامه‌ای بی‌خبر قالبش را عوض کرده و هر قاعده‌ای که آن فیلدها را می‌خواند بی‌سروصدا شکسته شده است.
داده‌های بی‌معنا. حجم زیادی از لاگ‌ها نویز است: پیام‌های دیباگ، لاگ‌های تکراری و رویدادهایی که هیچ ارزش تحلیلی ندارند. نویز هزینهٔ ذخیره‌سازی را بالا می‌برد و سیگنال را در تحلیل پایین می‌آورد.
پاسخ، فیلتر کردن در لبه است، پیش از آنکه داده به سیستم مرکزی برسد. سامانهٔ rsyslog دقیقاً برای همین کار طراحی شده است: کاهش داده پیش از رسیدن به سامانه‌های گران‌قیمت پایین‌دست.
امنیت خود سیستم لاگ
چالش سوم یک پارادوکس است: سیستمی که برای نظارت بر امنیت ساخته شده، خودش یک هدف است. اگر مهاجمی به SIEM دسترسی پیدا کند، می‌تواند شواهد را پاک کند، هشدارها را سرکوب کند یا از داده‌های لاگ برای یافتن نقاط ضعف دیگر استفاده کند.
در این حالت، سامانهٔ SIEM به یک هدف با ارزش بالا تبدیل می‌شود: نقطه‌ای مرکزی که همه‌چیز را می‌بیند و اگر به آن نفوذ شود، همه‌چیز را از دست می‌دهد. سه پیامد عملی از این خطر نتیجه می‌شود.
سامانهٔ SIEM یکی از جذاب‌ترین اهداف در کل ناوگان است. همهٔ سیگنال‌های امنیتی را در یک جا نگه می‌دارد، پس نفوذ به آن هم شواهد را نابود می‌کند، هم هشدارها را خاموش می‌کند و هم نقشهٔ دفاع‌های شما را به مهاجم می‌دهد. خودِ بستر لاگ را مانند حساس‌ترین سامانه‌ای که اجرا می‌کنید محافظت کنید.
کنترل دسترسی. دسترسی به SIEM باید بر اساس اصل حداقل دسترسی باشد. هیچ تحلیلگری به همهٔ مجموعه‌داده‌ها نیاز ندارد. یک مطالعه نشان داد که محدود کردن دسترسی به لاگ‌های خام به کمتر از ۲۰ درصد کارکنان SOC، احتمال نشت ناخواستهٔ داده را حدود ۶۴ درصد کاهش می‌دهد.
جداسازی داده‌های حساس. اگر داده‌های شخصی و رویدادهای امنیتی در یک جا ذخیره شوند، یک نفوذ همه را یک‌جا لو می‌دهد. پاسخ، نگه داشتن فیلدهای حساس در یک مخزن جداگانه و جایگزینی آن‌ها با توکن در سیستم اصلی است که حجم دادهٔ لو رفته در یک نفوذ را به‌شدت کم می‌کند.
یکپارچگی داده. اگر مهاجم بتواند لاگ‌ها را تغییر دهد، اعتبار شواهد از بین می‌رود. پاسخ، ذخیره‌سازی تغییرناپذیر است: رکورد پس از نوشتن قابل تغییر نیست.
لاگ‌های امنیتی را به‌شکل تغییرناپذیر نگه دارید و دسترسی به حذف را محدود کنید. مهاجمی که دسترسی نوشتن روی شواهد داشته باشد، ارزش آن‌ها را کاملاً از بین می‌برد و هیچ تحقیقی در آینده نمی‌تواند ثابت کند چه اتفاقی افتاده است.
حریم خصوصی و انطباق
چالش چهارم پیچیده‌ترین و قانونی‌ترین چالش است: لاگ‌ها حاوی داده‌های شخصی هستند. یک لاگ ورود نام کاربری دارد، یک لاگ دسترسی وب آدرس IP دارد و یک لاگ برنامه ممکن است ایمیل یا شماره تلفن داشته باشد.
قوانین حریم خصوصی از این داده‌ها محافظت می‌کنند و GDPR در اروپا شناخته‌شده‌ترین نمونهٔ آن است. حتی آدرس IP هم در برخی تفسیرهای GDPR دادهٔ شخصی محسوب می‌شود. یعنی طراحی سیستم لاگ مرکزی باید از ابتدا حریم خصوصی را در نظر بگیرد، نه به‌عنوان فکری برای بعد، و این کار بر سه اصل کلیدی استوار است.
کمینه‌سازی داده. فقط داده‌ای را جمع کنید که واقعاً به آن نیاز دارید. اگر یک فیلد برای تحلیل امنیتی ضروری نیست، آن را جمع نکنید. مادهٔ ۵.۱.c از GDPR صریحاً همین را الزام می‌کند و در عمل یعنی بازبینی منظم فیلدهای لاگ و حذف آن‌هایی که ارزش تحلیلی ندارند.
ماسک کردن. فیلدهای حساس مانند رمز عبور، شمارهٔ کارت اعتباری یا داده‌های سلامت باید پیش از ذخیره‌سازی ماسک شوند. یک مطالعه نشان داد که رمزنگاری انتخابی فیلدهای حساس به‌جای رمزنگاری کل رکورد، هم امنیت را حفظ می‌کند و هم کارایی جست‌وجو را به‌طور چشمگیری بهبود می‌دهد: تا ۵۴ درصد بهبود در throughput و تا ۴۲ درصد کاهش تأخیر پرس‌وجو.
کمینه‌سازی داده در GDPR قاعدهٔ جمع‌آوری است، نه قاعدهٔ ذخیره‌سازی: فیلدی که هرگز جمع نشود، در هیچ نشتی هم لو نمی‌رود. آن را با ماسک کردن در مبدأ ترکیب کنید، چون ماسک کردن تنها فیلدهایی که از قبل دارید، بقیهٔ رکورد را همچنان در معرض نگه می‌دارد.
دسترسی مبتنی بر نقش. هر کسی نباید به همهٔ لاگ‌ها دسترسی داشته باشد. یک تحلیلگر امنیتی ممکن است به لاگ‌های احراز هویت نیاز داشته باشد ولی نه به لاگ‌های برنامهٔ مالی. طراحی دسترسی باید بر اساس نیاز به دانستن باشد، نه راحتی.
انطباق. استانداردهای مختلف، الزامات متفاوتی برای نگهداری لاگ دارند. استاندارد PCI-DSS حداقل ۱۲ ماه نگهداری و ۳ ماه دسترسی فوری را الزام می‌کند. استاندارد HIPAA برای داده‌های سلامت سختگیرانه‌تر است و استاندارد SOC 2 بر کنترل‌های امنیتی تمرکز دارد. طراحی سیستم لاگ باید از ابتدا در برابر این الزامات انجام شود، چون تغییر آن پس از پیاده‌سازی، پرهزینه و زمان‌بر است.
در یک SIEM ابری یا سرویس مدیریت‌شده، تأمین‌کننده پردازشگر داده است و شما همچنان کنترل‌کننده باقی می‌مانید. باید بدانید داده کجا ذخیره می‌شود، چه کسی به آن دسترسی دارد و قرارداد در پایان مدت چه تعهدی برای حذف داده دارد.
زمان (NTP)
چالش پنجم کوچک به نظر می‌رسد ولی بنیادین است: ساعت. اگر ساعت سرورها همگام نباشد، ترتیب رویدادها در تحلیل به هم می‌ریزد.
استاندارد ISO 27001 در کنترل ۸.۱۷ صریحاً الزام می‌کند که ساعت همهٔ سیستم‌های پردازش اطلاعات با یک منبع زمان واحد همگام شود. این کنترل به‌ظاهر ساده است ولی تقریباً همهٔ جنبه‌های دیگر امنیت به آن وابسته است.
این پیامد یک اختلاف یک‌دقیقه‌ای در تحقیق است:
firewall suspicious connection detected 10:02:15
IDS same traffic observed 10:02:45
app server unexpected login 10:03:00
همین ترتیب، کل تحقیق است. اگر ساعت این سه سیستم حتی یک دقیقه اختلاف داشته باشد، تحلیلگر نمی‌تواند تشخیص دهد چه چیزی اول رخ داده و یک حملهٔ هماهنگ به نویزهای بی‌ربط تبدیل می‌شود.
راه‌حل، پروتکل NTP است: همهٔ دستگاه‌ها را با یک منبع زمان واحد همگام می‌کند. خودِ NTP هم باید امن باشد، چون مهاجمی که بتواند ساعت را جابه‌جا کند، شواهدی را که همه‌چیز به آن تکیه دارد مخدوش می‌کند.
پروتکل NTP یک پیش‌نیاز است، نه یک گزینه. معماری‌ای که آن را نداشته باشد روی شن متحرک ساخته شده است و خرابی‌اش خیلی دیرتر به شکل همبستگی‌ای ظاهر می‌شود که بی‌سروصدا جواب غلط می‌دهد.
ترافیک NTP را به سرورهای زمان مجاز محدود کنید، در صورت امکان آن را احراز هویت کنید و پایشش کنید. مهاجمی که ساعت را عقب می‌برد می‌تواند یک نفوذ را بیرون از هر پنجرهٔ نگهداری که به آن تکیه کرده‌اید پنهان کند.
نیروی انسانی و تنظیم مستمر
یک چالش در هیچ بروشوری نیست و جای خودش را در این بخش دارد: SIEM بدون نیروی انسانی متخصص، فقط یک صفحهٔ نمایش گران‌قیمت است. قواعد همبستگی باید نوشته، آزمایش و به‌روزرسانی شوند، هشدارهای کاذب باید کاهش یابند و تهدیدهای جدید الگوهای جدید می‌طلبند.
این کار یک پروژهٔ یک‌باره نیست، بلکه فرایندی مستمر است. سازمانی که SIEM می‌خرد ولی تیمی برای تنظیم آن اختصاص نمی‌دهد، در نهایت یک سیستم پر از هشدار کاذب دارد که تحلیلگران را فرسوده می‌کند و هشدارهای واقعی را در نویز گم می‌کند.
این همان چیزی است که در بخش ۴ دربارهٔ خستگی هشدار گفته شد. راه‌حل‌های فنی یعنی گروه‌بندی، امتیازدهی و غنی‌سازی، فقط وقتی کار می‌کنند که یک تیم انسانی پشت آن‌ها باشد و قواعد را تنظیم و بازبینی کند. بدون چنین تیمی، سامانهٔ SIEM به یک شاهزادهٔ خفته تبدیل می‌شود: گران، زیبا و بی‌فایده.
سامانهٔ SIEM را بدون تیمی برای ادارهٔ آن نخرید. SIEMای که کسی آن را تنظیم نمی‌کند، پرسر و صدا نمی‌شکست؛ آرام از کار می‌افتد و اعتماد تحلیلگر را می‌سوزاند تا جایی که کسی در نهایت هشدارها را خاموش کند.
جمع‌بندی
چالش‌های این بخش موانعی نیستند که بعداً حل شوند. آن‌ها بخشی از طراحی هستند و یک معمار لاگ مرکزی باید از روز اول به آن‌ها پاسخ دهد:
- چه چیزی را چقدر نگه می‌داریم و چرا؟ (هزینه و انطباق)
- چگونه مطمئن می‌شویم که همهٔ منابع حیاتی واقعاً لاگ می‌فرستند؟ (کیفیت داده)
- اگر سامانهٔ SIEM هک شود چه اتفاقی می‌افتد؟ (امنیت خود سیستم)
- چه داده‌های شخصی در لاگ‌ها هست و چگونه محافظت می‌شود؟ (حریم خصوصی)
- آیا ساعت همهٔ سیستم‌ها همگام است؟ (NTP)
- چه کسی قواعد را تنظیم و نگهداری می‌کند؟ (نیروی انسانی)
پاسخ این سؤالات، تفاوت میان یک سیستم لاگ مرکزی که در عمل کار می‌کند و یکی که فقط روی کاغذ خوب به نظر می‌رسد را مشخص می‌کند. همین پاسخ‌ها موضوع بخش بعدی هستند: سناریوهای کاملی که هر یک از این چالش‌ها را در موقعیت‌های واقعی نشان می‌دهند.
بخش قبل: بخش ۴ — SIEM در عمق · بخش بعد: بخش ۶ — سناریوهای کامل و حل مسئله · فهرست بخش‌ها