چرا Wazuh؟
Wazuh یک Agent چندسکویی و اجزای مرکزی شامل server، indexer و dashboard دارد. برای جمع‌آوری رخداد، File Integrity Monitoring، ارزیابی تنظیمات، تشخیص آسیب‌پذیری و Compliance استفاده می‌شود. قبل از rollout سازمانی، sizing و retention داده را براساس تعداد endpointها طراحی کنید.
دریافت امن
برای دانلود از دکمه «دانلود رسمی» همین صفحه استفاده کنید. IROSG فایل installer این نرم‌افزار را mirror نمی‌کند تا کاربر همیشه به نسخه و signature رسمی سازنده دسترسی داشته باشد.
استفاده مسئولانه
در ابزارهای تحلیل، اسکن و Penetration Testing، Scope و مجوز روشن بخشی از کار فنی است. تنظیمات و رفتار ابزار را ابتدا در Lab بررسی کنید و سپس در محیط Production به‌کار ببرید.
انتخاب Wazuh را با یک مسئله مشخص شروع کنید
پیش از نصب، بنویسید کدام سؤال امنیتی باید پاسخ داده شود. آیا می‌خواهید تغییر فایل‌های مهم را ببینید، وضعیت بسته‌های نصب‌شده را بررسی کنید یا رخدادهای ورود را در چند سیستم کنار هم بگذارید؟ هر کدام داده، قواعد و فرایند رسیدگی متفاوتی نیاز دارند. نصب همه قابلیت‌ها بدون هدف می‌تواند حجم زیادی هشدار ایجاد کند که کسی مسئول بررسی آن نیست. یک شروع محدود با خروجی روشن، برای تیم کوچک معمولاً قابل نگهداری‌تر است و امکان سنجش ارزش واقعی سامانه را می‌دهد.
برای نمونه، هدف نخست را مشاهده تغییر یک فایل تنظیمات غیرحساس در چند ماشین آزمایشی قرار دهید. مشخص کنید تغییر مجاز چگونه ثبت می‌شود و تغییر غیرمنتظره چه اقدامی می‌طلبد. سپس یک نمونه ورود ناموفق ساختگی اضافه کنید. این دو مورد به تیم امکان می‌دهند تفاوت داده موجودی، رخداد و هشدار را بفهمد. بعد از تثبیت این جریان، می‌توان دامنه را به گروه دیگری از میزبان‌ها یا قابلیت‌ها گسترش داد.
آماده‌سازی محیط ارزیابی
یک محیط آزمایشی باید از نظر سیستم‌عامل و نوع بار به بخشی از محیط واقعی شباهت داشته باشد. تنها یک ماشین تمیز بدون برنامه نماینده همه سازمان نیست. چند میزبان با نقش‌های متفاوت انتخاب کنید، اما تعداد را آن‌قدر زیاد نکنید که تحلیل نتیجه دشوار شود. نام، مالک و هدف هر میزبان را ثبت کنید. داده ساختگی و حساب‌های محدود به کار ببرید تا خروجی بررسی قابل اشتراک باشد و اطلاعات مشتری وارد گزارش آموزشی نشود.
پیش از نصب، منابع موجود و مسیر ارتباط عامل با اجزای مرکزی را بررسی کنید. محدودیت شبکه، نام‌حل‌کنی و ساعت سیستم می‌توانند روی نتیجه اثر بگذارند. اگر نصب از مخزن یا بسته رسمی انجام می‌شود، روش تأیید اصالت و نسخه را مطابق مستندات همان انتشار دنبال کنید. هدف این مرحله فقط بالا آمدن رابط نیست؛ باید بتوانید بعداً محیط را دوباره بسازید و توضیح دهید هر جزء از کجا آمده و با چه تنظیمی اجرا می‌شود.
نصب عامل و ثبت هویت دستگاه
عامل باید به دستگاه درست و گروه مناسب نسبت داده شود. نام‌های تکراری یا عامل‌های باقی‌مانده از ماشین‌های حذف‌شده می‌توانند تحلیل را گیج کنند. پس از ثبت، شناسه عامل را با موجودی دارایی تطبیق دهید و یک رخداد ساختگی از همان میزبان تولید کنید. ظاهر شدن نام دستگاه در داشبورد، به تنهایی تضمین نمی‌کند داده مورد نظر شما جمع می‌شود. مسیر داده را با یک شاهد قابل جست‌وجو بررسی کنید.
برای rollout، گروه‌های کوچک و قابل بازگشت انتخاب کنید. ابتدا سیستم‌های کم‌خطر و سپس نقش‌های حساس‌تر را اضافه کنید. مصرف منابع عامل، حجم داده ارسالی و اثر بر کار برنامه را مشاهده کنید. اگر یک تنظیم جمع‌آوری بیش‌ازحد پرحجم است، قبل از گسترش آن را اصلاح کنید. تعداد عامل نصب‌شده معیار پیشرفت مفیدی است، اما باید کنار تعداد میزبان‌هایی قرار گیرد که داده درست و قابل اقدام از آنها دریافت می‌شود.
File Integrity Monitoring را هدفمند تنظیم کنید
پایش یکپارچگی فایل برای تشخیص تغییر در مسیرهای مهم مفید است، اما انتخاب مسیر باید با معنای فایل هماهنگ باشد. پوشه‌ای که هر ثانیه فایل موقت می‌سازد رفتار متفاوتی از فایل تنظیمات حساس دارد. اگر همه مسیرها را بدون تفکیک پایش کنید، نویز ممکن است تغییر مهم را پنهان کند. ابتدا چند مسیر با ارزش مشخص انتخاب کنید و نوع تغییر مورد انتظار را بنویسید: محتوا، مالکیت یا مجوز. سپس تغییر مجاز و غیرمنتظره را با داده ساختگی آزمایش کنید.
نتیجه تغییر فایل باید با فرایند مدیریت تغییر مرتبط شود. یک به‌روزرسانی رسمی می‌تواند صدها فایل را تغییر دهد و این الزاماً حادثه نیست. در مقابل، تغییر کوچک خارج از پنجره نگهداری ممکن است نیازمند بررسی باشد. برای تحلیل، زمان، حساب مرتبط و سابقه تغییر را کنار هشدار قرار دهید. ابزار می‌تواند تغییر را نشان دهد، اما تصمیم درباره مجاز بودن آن به زمینه عملیاتی نیاز دارد. این زمینه باید برای تحلیلگر قابل دسترس باشد.
ارزیابی تنظیمات و تفسیر عدم انطباق
نتیجه ارزیابی تنظیمات را فهرستی از سؤال‌های قابل بررسی بدانید. یک قاعده ممکن است برای نقش خاص ماشین مناسب باشد ولی برای نقش دیگر نیاز به استثنای مستند داشته باشد. همه موارد ناموفق را بدون بررسی با یک اسکریپت اصلاح نکنید؛ تغییر می‌تواند سرویس را مختل کند. ابتدا دلیل کنترل، وضعیت واقعی و اثر اصلاح را بفهمید. سپس روی ماشین آزمایشی مشابه اعمال کنید و کارکرد اصلی را بسنجید.
برای استثنا، دلیل، مالک و تاریخ بازبینی لازم است. جمله «این سرور خاص است» توضیح کافی نیست. بنویسید کدام وابستگی مانع تغییر است و چه کنترل مکملی وجود دارد. در بازبینی بعدی، بررسی کنید آیا آن وابستگی هنوز برقرار است. این روش مانع می‌شود گزارش انطباق به مجموعه‌ای از استثناهای دائمی و بی‌معنا تبدیل شود. هدف درصد سبز بالا بدون فهم نیست؛ هدف کاهش ریسک با تغییر قابل توضیح است.
یافته آسیب‌پذیری را با زمینه دارایی اولویت‌بندی کنید
گزارش آسیب‌پذیری باید با نسخه بسته، وضعیت وصله و نقش سیستم بررسی شود. نام یک شناسه آسیب‌پذیری به تنهایی اولویت نهایی را تعیین نمی‌کند. دسترسی مهاجم به سرویس، وجود کنترل مکمل و حساسیت داده نیز مهم‌اند. همچنین روش نسخه‌بندی و بازپورت وصله در توزیع می‌تواند در تفسیر نتیجه اثر داشته باشد. هنگام اختلاف، به اعلامیه رسمی توزیع و وضعیت بسته واقعی مراجعه کنید و نتیجه بررسی را در پرونده ثبت کنید.
برای اصلاح، یک گروه کوچک از میزبان‌های مشابه انتخاب کنید. پس از وصله، نسخه و سلامت برنامه را بررسی کنید و سپس به‌روز شدن اطلاعات موجودی و گزارش را دنبال کنید. اگر یافته هنوز دیده می‌شود، ممکن است چرخه جمع‌آوری یا تطبیق هنوز تکمیل نشده باشد؛ فوراً فرض نکنید وصله شکست خورده است. در عین حال حذف دستی هشدار بدون شاهد اصلاح نیز مناسب نیست. نتیجه باید به وضعیت واقعی دارایی و شواهد قابل بازبینی متصل بماند.
کاهش نویز بدون از دست دادن دید
هشدار پرتکرار را با نمونه‌های واقعی بررسی کنید. آیا قاعده بیش‌ازحد عمومی است، داده زمینه کم است یا رفتار مجاز سازمان به درستی شناخته نشده؟ اصلاح باید همان علت را هدف بگیرد. خاموش کردن همه هشدارهای یک منبع می‌تواند دید لازم برای رخداد مهم را حذف کند. برای هر تغییر قاعده، یک نمونه بی‌خطر و یک نمونه مورد انتظار برای تشخیص داشته باشید. هر دو را پس از تغییر دوباره بسنجید.
تحلیلگر باید بداند با هشدار چه کند. یک راهنمای کوتاه می‌تواند شامل سؤال‌های بررسی، منابع زمینه و معیار ارجاع باشد. اگر هشدار هیچ تصمیمی ایجاد نمی‌کند، شاید نیاز به غنی‌سازی یا تغییر سطح دارد. زمان رسیدگی و تعداد موارد تکراری را ثبت کنید تا هزینه عملیاتی معلوم شود. سامانه امنیتی زمانی ارزش دارد که خروجی آن به اقدام مناسب برسد، نه اینکه صرفاً حجم بزرگی از رویداد را در نمودار نمایش دهد.
پاسخ خودکار را جدا از مشاهده ارزیابی کنید
قابلیت پاسخ می‌تواند اثر مستقیم بر میزبان یا دسترسی داشته باشد. پیش از فعال کردن، محرک، دامنه و راه بازگشت را مشخص کنید. یک هشدار اشتباه نباید بدون کنترل به قطع سرویس حیاتی تبدیل شود. ابتدا در محیط آزمایش و با هدف ساختگی رفتار را ببینید. سپس در دامنه محدود و با نظارت، اثر واقعی و پیامدهای جانبی را بررسی کنید. داشتن امکان اجرای پاسخ به معنی مناسب بودن آن برای همه قواعد نیست.
برای هر پاسخ، مشخص کنید چه کسی اجازه تغییر آن را دارد و چگونه اقدام ثبت می‌شود. اگر حساب یا نشانی مسدود شد، تیم پشتیبانی باید راه تشخیص و رفع اثر را بداند. در تمرین، یک مورد مثبت کاذب کنترل‌شده بسازید و بازیابی را انجام دهید. این آزمایش نشان می‌دهد فرایند تنها برای موفقیت طراحی نشده و در حالت اشتباه نیز قابل مدیریت است. مسئولیت تصمیم امنیتی و مسئولیت تداوم خدمت باید در این طرح با هم دیده شوند.
حفاظت از داده و دسترسی تیم
لاگ‌ها می‌توانند شامل اطلاعات شخصی، نام فایل و جزئیات زیرساخت باشند. دسترسی تحلیلگر، مدیر سامانه و توسعه‌دهنده را بر اساس نیاز جدا کنید. گزارش‌های اشتراکی را پاک‌سازی کنید و از ارسال توکن یا محتوای حساس به سامانه‌های عمومی خودداری کنید. مدت نگهداری را با هدف بررسی و سیاست سازمان هماهنگ کنید. نگهداری همه چیز برای همیشه، به خودی خود امنیت بیشتر ایجاد نمی‌کند و می‌تواند هزینه و دامنه افشا را افزایش دهد.
حساب‌های مدیریتی و ارتباط اجزای مرکزی نیز باید نگهداری شوند. گواهی، اعتبارنامه و مسیر بازیابی آنها را در برنامه عملیات بگنجانید. آزمون بازیابی فقط بازگرداندن داده نیست؛ تنظیم قواعد و توان ورود تیم نیز باید برگردد. یک سناریوی بازیابی در محیط جدا نشان دهد که رویداد مشخص قابل مشاهده است و نقش محدود همچنان محدود مانده است. این بررسی ترکیبی از صحت داده و صحت کنترل دسترسی است.
معیار تصمیم پس از دوره آزمایشی
در پایان ارزیابی، چند سؤال روشن پاسخ دهید: آیا داده مورد نیاز دریافت شد، هشدار قابل اقدام بود، هزینه منابع قابل قبول بود و تیم توانست نتیجه را پیگیری کند؟ نقاطی را که هنوز پوشش ندارند صریح بنویسید. ممکن است لازم باشد منبع لاگ تازه‌ای اضافه شود یا ابزار مکملی برای پاسخ در نظر گرفته شود. تصمیم به گسترش باید بر اساس این شواهد باشد. یک داشبورد زیبا یا نصب موفق به تنهایی نشان نمی‌دهد سازمان به قابلیت تشخیص و رسیدگی پایدار رسیده است.
