شیفت مرکز عملیات امنیت با یک داشبورد آرام شروع میشود؛ هیچ هشدار مهمی دیده نمیشود و به نظر میرسد شب گذشته بدون حادثه گذشته است. چند ساعت بعد مشخص میشود یکی از منابع حیاتی از نیمهشب هیچ لاگی ارسال نکرده است. مسئله فقط از دست رفتن چند پیام نیست: تیم امنیت درباره بازهای تصمیم گرفته که شواهد کافی از آن نداشته است.
قطع دریافت لاگ باید خودش یک رخداد قابل پیگیری باشد. در این راهنما، با تکیه بر مستندات EventLog Analyzer، تفاوت خرابی جمعآورنده، سکوت یک منبع و اختلال پردازش را بررسی میکنیم. روش گروهبندی، آزمون و پاسخ ارائهشده، پیشنهاد اجرایی برای سازمان است؛ آستانهها باید با اهمیت منابع و امکانات نسخه نصبشده تطبیق داده شوند.
نبود هشدار، سلامت سامانه را ثابت نمیکند
در طراحی پایش امنیت، دو سؤال متفاوت داریم: آیا رویداد مشکوکی رخ داده است و آیا داده لازم برای تشخیص آن به سامانه میرسد؟ پاسخ منفی به سؤال اول، بدون پاسخ روشن به سؤال دوم، قابل اتکا نیست. برای هر منبع حساس باید مسیر تولید، انتقال، دریافت و قابل جستوجو شدن رویداد معلوم باشد.
فهرست منابع را با موجودی داراییها تطبیق دهید. یک دستگاه جدید ممکن است وارد محیط تولید شده باشد اما هرگز به پایش اضافه نشده باشد؛ هشدار سکوت برای منبعی که اصلاً تعریف نشده، کمکی نمیکند. مسئول منبع، نوع لاگ، روش جمعآوری و زمان آخرین آزمون را در پرونده آن نگه دارید.
دو هشدار متفاوت را با هم اشتباه نگیرید
طبق راهنمای رسمی خرابی جمعآورنده، EventLog Analyzer میتواند توقف غیرمنتظره یا خرابی سرویس داخلی جمعآوری را با ایمیل اطلاع دهد. گزینه مربوط در مسیر Settings، سپس Admin Settings، Product Settings و Product Notification با نام Log Collector Failure معرفی شده است. پیکربندی سرویس ایمیل نیز پیشنیاز ارسال اعلان است.
این کنترل با هشدار نرسیدن لاگ از یک دستگاه فرق دارد. ممکن است جمعآورنده سالم باشد اما ارتباط با یک سرور، حساب جمعآوری یا تنظیم ارسال آن مشکل داشته باشد. بنابراین فعال کردن یکی از این هشدارها، جای دیگری را نمیگیرد.
| نشانه | دامنه احتمالی مشکل | بررسی اولیه |
|---|---|---|
| چندین منبع همزمان ساکت شدهاند | جمعآورنده یا زیرساخت مشترک | وضعیت سرویس، شبکه و ذخیرهسازی |
| فقط یک منبع لاگ ندارد | دستگاه یا مسیر اختصاصی آن | تولید محلی رویداد، دسترسی و تنظیم ارسال |
| داده دریافت میشود ولی جستوجو عقب است | پردازش یا نمایهسازی | زمان دریافت در برابر زمان قابل جستوجو شدن |
| رویدادها با زمان نامعتبر دیده میشوند | ساعت یا منطقه زمانی | همگامی ساعت منبع و سامانه |
جدول بالا ابزار تشخیص اولیه است، نه حکم قطعی درباره علت. خاموشی برنامهریزیشده یک شعبه و شکست دسترسی به همان شعبه میتوانند نشانه مشابه ایجاد کنند؛ تفاوت آنها را باید با شواهد عملیاتی مشخص کرد.
هشدار نرسیدن داده را برای منابع مهم فعال کنید
مستند تنظیم هشدار شکست جمعآوری، مسیر Settings، Admin Settings و Log Collection Failure Alerts را معرفی میکند. در این بخش میتوان دستگاه یا گروه را انتخاب، Device Down Alert را فعال و گیرندگان و بازه اعلان را تنظیم کرد. مستند فعلی، حداقل فاصله قابل تنظیم را ۳۰ دقیقه اعلام میکند و گزینه Notify once را برای جلوگیری از اعلانهای تکراری توضیح میدهد.
اگر نیاز عملیاتی شما تشخیص سریعتر است، صرفاً یک هدف کوتاهتر در سند ننویسید؛ باید کنترل مکمل و سازگار با محیط طراحی و آزمون شود. نام منوها و محدودیتها نیز پیش از اجرا با راهنمای نسخه واقعی تطبیق داده شوند.
آخرین اسکن با آخرین پیام یکسان نیست
در توضیح رسمی رفتار هشدار، برای دستگاههای ویندوز زمان آخرین اسکن و برای منابع Syslog زمان آخرین پیام مبنا قرار میگیرد. در نتیجه، نبود پیام در یک منبع کمفعالیت لزوماً به معنی خرابی نیست؛ همانطور که موفقیت ارتباط شبکه نیز بهتنهایی رسیدن رویداد مورد انتظار را ثابت نمیکند.
پیشنهاد عملی این است که منابع کمفعالیت، پرترافیک و حیاتی را از یکدیگر جدا کنید. برای منبع حساس، یک رویداد آزمایشی مجاز و قابل شناسایی تعریف کنید تا بتوان مسیر کامل را بررسی کرد. این آزمون نباید با ایجاد حمله واقعی یا دستکاری داده تولید انجام شود.
پاسخ عملیاتی به قطع دریافت لاگ
ابتدا نقطه شروع شکاف را پیدا کنید
زمان آخرین داده معتبر، زمان اولین اعلان و زمان شروع بررسی را ثبت کنید. سپس مشخص کنید کدام منابع و کدام انواع رویداد متأثر شدهاند. ممکن است لاگ برنامه برسد اما لاگ امنیت همان سرور قطع باشد. گزارش «سرور سالم است» بدون تفکیک نوع داده کافی نیست.
مسیر را از منبع تا جستوجو دنبال کنید
بررسی کنید رویداد در محل اصلی تولید شده است یا نه؛ بعد به سراغ روش انتقال، مجوز حساب، وضعیت عامل و مقصد بروید. تغییر اخیر فایروال، تعویض رمز حساب جمعآوری یا محدودیت ذخیرهسازی را با زمان شروع مشکل مقایسه کنید. برای شناخت تفاوت مسیرها، راهنمای معماری جمعآوری لاگ مدانت مکمل این بررسی است.
رفع علت را با بازگشت داده اثبات کنید
راهاندازی مجدد سرویس، پایان کار نیست. یک رویداد مجاز جدید ایجاد کنید و شناسه، منبع و زمان آن را در نتیجه جستوجو تطبیق دهید. پس از بازگشت جریان، بررسی کنید دادههای بازه قطعی قابل بازیابی هستند یا بخشی از شواهد از دست رفته است. این دو نتیجه باید جداگانه ثبت شوند.
بازیابی داده گمشده را تضمینشده فرض نکنید
امکان جبران شکاف به روش انتقال، ماندگاری رویداد در منبع، ظرفیت بافر و تنظیمات محیط وابسته است. وقتی داده در منبع نگهداری نشده یا بازنویسی شده است، وصل شدن دوباره ارتباط بهخودیخود آن را بازسازی نمیکند. بنابراین عبارت «همه لاگها برگشت» فقط پس از تطبیق شواهد و بررسی بازه زمانی قابل استفاده است.
برای منابع حیاتی، ظرفیت نگهداری محلی را با مدت اختلال قابل انتظار مقایسه کنید و هنگام آزمون بازیابی، پوشش زمانی را بسنجید. این موضوع از نگهداری بلندمدت آرشیو جداست؛ راهنمای نگهداری و آرشیو لاگ به بخش دوم میپردازد.
پنج آزمون پذیرش برای تحویل سامانه
| آزمون کنترلشده | نتیجه مورد انتظار | شاهد لازم |
|---|---|---|
| قطع مسیر یک منبع آزمایشی | اعلان متناسب با آستانه پیکربندیشده | زمان قطع و دریافت اعلان |
| بازگرداندن ارتباط | رسیدن رویداد تازه | تطبیق شناسه و زمان رویداد |
| اختلال در کانال اعلان آزمایشی | آشکار شدن مشکل ارسال | نتیجه آزمون تحویل پیام |
| خاموشی برنامهریزیشده | تفکیک نگهداری از خرابی غیرمنتظره | ثبت بازه و مسئول نگهداری |
| بررسی بازه قطعی | تعیین پوشش بازیابی و شکاف باقیمانده | گزارش تطبیق زمانی |
آزمون خرابی خود جمعآورنده را در محیط آزمایشی یا پنجره مجاز انجام دهید؛ پایش تولید نباید برای آزمایش بیبرنامه از دسترس خارج شود. همچنین مسیر اعلان را طوری طراحی کنید که خرابی همان میزبان، همه راههای خبردار شدن تیم را هم از بین نبرد.
شاخصی که کیفیت پایش را نشان میدهد
به جای شمار هشدارهای تولیدشده، سهم منابع حیاتی دارای کنترل سلامت، مدت شکاف دریافت و زمان رسیدگی به آن را گزارش کنید. منابعی که بدون مسئول هستند یا آخرین آزمون آنها نامعلوم است نیز باید دیده شوند. تعداد کم هشدار، وقتی پوشش منابع ناقص است، موفقیت امنیتی نیست.
در گزارش رخداد، دامنه عدم قطعیت را صریح بنویسید: چه بازهای فاقد داده معتبر بوده و چه بررسی جایگزینی انجام شده است. این شفافیت برای تصمیمگیری مدیر امنیت مفیدتر از یک داشبورد سبز بدون توضیح است.
نکات کلیدی
- سلامت جمعآورنده و سلامت جریان هر منبع، دو کنترل مستقلاند.
- آخرین اسکن، آخرین پیام و زمان قابل جستوجو شدن داده را از هم جدا کنید.
- بعد از رفع ارتباط، پوشش دادههای بازه قطعی را نیز بررسی کنید.
- آزمون انتهابهانتها و مسئول پاسخ، بخشی از تحویل سامانه لاگ هستند.
سخن پایانی
سامانه امنیتی باید هم تهدید را ببیند و هم متوجه شود چه زمانی دیگر قادر به دیدن نیست. تشخیص قطع دریافت لاگ، این نقطه کور را به مسئلهای قابل اندازهگیری و قابل پیگیری تبدیل میکند؛ به شرط آنکه اعلان، آزمون و بازیابی شواهد با هم طراحی شوند.
برای استعلام لایسنس EventLog Analyzer و طراحی جمعآوری، هشدار سلامت و نگهداری داده، از خدمات مدانت استفاده کنید. در پروژههای گستردهتر مدیریت رویدادهای امنیتی با Log360 نیز کیفیت ورودی باید بخشی از معیار پذیرش باشد. دامنه استقرار و پشتیبانی را میتوان در جلسه فنی مدانت مشخص کرد.
منابع
- اعلان خرابی جمعآورنده در EventLog Analyzer
- پیکربندی هشدار نرسیدن لاگ
- توضیح معیارهای تشخیص و هشدارهای محصول
