از گزارش ممیزی تا تصمیم عملی
Lynis ابزاری برای ممیزی امنیتی سیستم‌های شبه‌یونیکس است. این ابزار وضعیت میزبان را بررسی می‌کند و درباره تنظیمات، سرویس‌ها و کنترل‌های قابل بهبود گزارش می‌دهد. کاربرد مناسب آن زمانی است که مدیر سیستم می‌خواهد دید منظم‌تری از وضعیت یک میزبان به دست آورد و یافته‌ها را به برنامه سخت‌سازی تبدیل کند. یک اجرای موفق به معنای امن شدن سیستم نیست؛ نتیجه، مواد اولیه تصمیم مهندسی است. هر پیشنهاد باید با نقش میزبان، نیاز سرویس و خطر تغییر سنجیده شود. نصب ابزار و بایگانی گزارش بدون تعیین مسئول اصلاح، ارزش محدودی ایجاد می‌کند.
راهنمای رسمی CISOfy روش نصب، اجرا، پروفایل و تفسیر هشدارها را توضیح می‌دهد. Lynis بسیاری از آزمون‌ها را بر اساس آنچه روی میزبان پیدا می‌کند انتخاب می‌کند؛ بنابراین نتیجه دو سیستم با نقش متفاوت الزاماً قابل مقایسه مستقیم نیست. یک سرور پایگاه داده و یک ایستگاه توسعه نیازهای یکسان ندارند. مقایسه باید در گروه دارایی‌های مشابه و با نسخه و تنظیمات معلوم انجام شود. این نکته مانع تبدیل ممیزی به مسابقه عددی میان تیم‌هایی می‌شود که مسئولیت‌های متفاوت دارند.
تعیین دامنه و آماده‌سازی
ابتدا هدف ممیزی را بنویسید. آیا می‌خواهید میزبان تازه را پیش از تحویل بررسی کنید، تغییرات ماه گذشته را ببینید یا برای یک بازبینی داخلی شواهد جمع کنید؟ پاسخ، روش ثبت و تکرار اجرا را تعیین می‌کند. برای میزبان تازه، خط مبنای اولیه اهمیت دارد؛ برای میزبان فعال، مقایسه با اجرای پیشین و درخواست‌های تغییر مهم‌تر است. هدف روشن کمک می‌کند گزارش شامل کارهای قابل اقدام باشد و همه پیشنهادها بدون اولویت به تیم عملیات منتقل نشوند.
پیش از اجرا، مالک سیستم و نقش سرویس را ثبت کنید. زمان مناسب را با بار کاری هماهنگ کنید و ظرفیت ثبت گزارش را در نظر بگیرید. ممیزی معمولاً با آزمون‌های بررسی وضعیت انجام می‌شود، اما هر ابزار جدید باید ابتدا روی محیط نماینده آزمایش شود. اجرای با دسترسی محدود ممکن است تصویر ناقص‌تری بدهد؛ اجرای با امتیاز مدیریتی نیز باید از مسیر قابل اعتماد انجام شود. نسخه رسمی یا بسته معتبر توزیع را انتخاب کنید و منشأ ابزار را ثبت نمایید. دانلود یک اسکریپت از محل نامعلوم و اجرای مستقیم با دسترسی بالا با هدف ممیزی سازگار نیست.
نخستین اجرا و حفظ نتیجه
در اجرای نخست، گزارش را بدون تلاش فوری برای رفع همه موارد بخوانید. شناخت شکل خروجی و تفاوت هشدار با پیشنهاد اهمیت دارد. گزارش تفصیلی برای فهم علت آزمون و فایل نتیجه برای پردازش بعدی مفید هستند؛ مسیرها و قالب دقیق را از نسخه نصب‌شده بررسی کنید. همراه گزارش، نام میزبان، تاریخ، نسخه ابزار و پروفایل فعال را نگه دارید. اگر این اطلاعات ثبت نشوند، مقایسه آینده ممکن است تغییر آزمون را با تغییر وضعیت سیستم اشتباه بگیرد.
یک نسخه از گزارش اولیه را در محل با کنترل دسترسی نگهداری کنید. گزارش می‌تواند نام سرویس‌ها، بسته‌ها و جزئیات پیکربندی را آشکار کند. انتشار عمومی آن حتی بدون گذرواژه ممکن است اطلاعات مفیدی درباره ساختار داخلی بدهد. برای گزارش مدیریتی، خلاصه و وضعیت اقدام معمولاً کافی است. جزئیات فنی باید در اختیار کسانی باشد که مسئول بررسی و اصلاح هستند. همچنین مطمئن شوید کار زمان‌بندی‌شده اجرای بعدی، تنها نسخه شواهد قبلی را بی‌خبر جایگزین نمی‌کند.
چرا امتیاز نهایی همه چیز نیست؟
شاخص سخت‌سازی می‌تواند برای مشاهده روند مفید باشد، اما به تنهایی معیار ریسک نیست. تغییر کوچک ممکن است امتیاز را بهتر کند، در حالی که مسئله مهمی مانند سرویس بلااستفاده در معرض شبکه باقی مانده باشد. برعکس، یک کنترل لازم برای نقش خاص میزبان ممکن است با توصیه عمومی متفاوت باشد و نیاز به توضیح داشته باشد. تصمیم را بر اساس اثر امنیتی، امکان سوءاستفاده و هزینه اصلاح بگیرید. عدد نهایی باید بخشی از گزارش باشد، نه جانشین تحلیل.
برای جلوگیری از هدف‌گیری عدد، یافته‌ها را به چند دسته عملی تقسیم کنید: مسئله‌ای که باید سریع بررسی شود، بهبود برنامه‌ریزی‌شده، مورد نیازمند اطلاعات بیشتر و موردی که با دلیل پذیرفته شده است. این دسته‌بندی باید قابل تغییر باشد؛ پذیرفتن یک وضعیت برای همیشه منطقی نیست. اگر نقش میزبان تغییر کرد یا سرویس تازه‌ای نصب شد، تصمیم قبلی باید بازبینی شود. ثبت دلیل باعث می‌شود تیم بعدی بداند چرا یک پیشنهاد اجرا نشده و مجبور نباشد همان بحث را تکرار کند.
تبدیل پیشنهاد به تغییر قابل آزمون
فرض کنید ممیزی تنظیمی را درباره سرویس ورود راه دور پیشنهاد می‌کند. قبل از تغییر، مسیرهای ورود مجاز، حساب‌های خودکار و روش بازیابی را مشخص کنید. تغییر مستقیم روی همه سرورها می‌تواند دسترسی مدیران یا کارهای زمان‌بندی‌شده را قطع کند. ابتدا روی یک میزبان آزمایش اعمال کنید، ورود جدید را بررسی کنید و راه بازگشت را آماده نگه دارید. بسته شدن جلسه فعلی یا باز ماندن آن به تنهایی اثبات نمی‌کند تنظیم تازه درست کار می‌کند؛ یک اتصال تازه باید آزموده شود.
همین منطق برای مجوز فایل، سیاست ثبت رویداد و تنظیمات کرنل نیز صادق است. پیشنهاد ممیزی معمولاً زمینه کامل برنامه را نمی‌داند. تغییر مجوز ممکن است امنیت را بهتر کند ولی سرویس را از خواندن فایل ضروری محروم سازد. آزمون باید هم نتیجه امنیتی و هم کارکرد برنامه را بسنجد. معیار پذیرش را پیش از تغییر بنویسید: چه دسترسی‌ای باید ممنوع شود و چه عملیات مشروعی باید همچنان موفق بماند. این دو معیار کنار هم از اصلاح ظاهری و خرابی پنهان جلوگیری می‌کنند.
پروفایل و استثناهای قابل نگهداری
در محیط چندمیزبانه، تنظیمات ممیزی باید قابل تکرار باشند. پروفایل مشخص می‌کند چه آزمون‌ها و چه رفتارهایی مورد انتظار است. تغییرات محلی را با توضیح نگه دارید و نسخه پروفایل را در گزارش ثبت کنید. اگر آزمونی برای گروهی از میزبان‌ها مناسب نیست، دلیل آن باید به نقش همان گروه متصل باشد. خاموش کردن یک آزمون برای کل سازمان به دلیل مشکل روی یک میزبان، دامنه دید را بی‌جهت کاهش می‌دهد. استفاده از گروه‌های محدود و نام‌گذاری روشن به نگهداری کمک می‌کند.
استثنا باید تاریخ بازبینی داشته باشد. برای مثال ممکن است یک نرم‌افزار قدیمی فعلاً به تنظیمی نیاز داشته باشد که مطلوب نیست. در این صورت برنامه جایگزینی یا ارتقا، کنترل جبرانی و مسئول پیگیری را ثبت کنید. وقتی نرم‌افزار حذف شد، استثنا نیز باید حذف شود. فهرست بلند استثناهای بدون مالک، گزارش را به مرور کم‌ارزش می‌کند. بازبینی دوره‌ای می‌تواند نشان دهد کدام استثنا واقعاً لازم است و کدام فقط از نسخه‌های قدیمی پیکربندی باقی مانده است.
ممیزی دوره‌ای و تشخیص تغییر
اجرای دوره‌ای زمانی مفید است که اختلاف‌ها دیده شوند. اگر هر هفته گزارشی تولید شود ولی کسی آن را نخواند، کنترل عملی شکل نگرفته است. بهتر است تغییر یافته‌ها، خطاهای اجرای ممیزی و میزبان‌های فاقد گزارش تازه به صورت خلاصه مشخص شوند. نبود گزارش یک میزبان نباید با نبود مشکل اشتباه شود. ممکن است کار زمان‌بندی‌شده متوقف شده، مجوز تغییر کرده یا ابزار حذف شده باشد. سلامت فرایند ممیزی بخشی از همان کنترل است و باید مالک داشته باشد.
مقایسه را با درخواست‌های تغییر ترکیب کنید. نصب یک سرویس جدید می‌تواند علت یافته تازه باشد و این اطلاعات به سرعت بررسی کمک می‌کند. اگر تغییر ثبت‌شده‌ای وجود ندارد، یافته ارزش بررسی بیشتری پیدا می‌کند، اما هنوز به معنای نفوذ قطعی نیست. ممکن است به‌روزرسانی بسته یا تغییر خود آزمون عامل آن باشد. گزارش باید زنجیره استدلال را حفظ کند: چه چیزی تغییر کرده، چه شواهدی داریم و چرا تصمیم خاصی گرفته‌ایم. این روش از واکنش عجولانه به هر اختلاف جلوگیری می‌کند.
استفاده در تصویر پایه و تحویل سرور
Lynis می‌تواند در ارزیابی تصویر پایه یا مرحله تحویل میزبان نقش داشته باشد. نتیجه ممیزی پیش از تحویل، خط مبنایی برای تغییرات آینده ایجاد می‌کند. با این حال تصویری که در آزمایش خوب ارزیابی شده ممکن است پس از دریافت تنظیمات تولید وضعیت دیگری داشته باشد. بنابراین بررسی پس از استقرار نیز ارزش دارد. اطلاعاتی مانند سرویس فعال، mount و سیاست دسترسی ممکن است در زمان اجرا تعیین شوند و در تصویر خام قابل ارزیابی کامل نباشند.
در فرایند تحویل، گزارش را به مجموعه‌ای کوچک از معیارهای پذیرش متصل کنید. برای نمونه، هیچ یافته بررسی‌نشده با اولویت توافق‌شده باقی نماند، استثناها مالک داشته باشند و مسیر ورود مدیریتی پس از سخت‌سازی آزموده شده باشد. این معیارها قابل فهم‌تر از درخواست مبهم «سرور باید امن باشد» هستند. تیم دریافت‌کننده نیز باید بداند چه کنترل‌هایی اجرا شده و چه مسئولیت‌هایی به نگهداری روزمره منتقل می‌شود. تحویل گزارش بدون توضیح، انتقال دانش محسوب نمی‌شود.
محدودیت‌ها و انتخاب ابزار مکمل
ممیزی پیکربندی با پایش رفتار لحظه‌ای یا آزمون نفوذ یکسان نیست. یک میزبان می‌تواند پیشنهادهای ممیزی را رعایت کند و همچنان به دلیل نقص برنامه، اعتبارنامه افشاشده یا دسترسی اشتباه در سرویس ابری آسیب ببیند. نتیجه Lynis را در کنار مدیریت وصله، ثبت رویداد و کنترل دسترسی ببینید. همچنین نبود یافته درباره یک موضوع ممکن است به معنای خارج بودن آن از دامنه آزمون باشد. گزارش خوب به محدودیت داده و آزمون اشاره می‌کند و از ادعای گواهی جامع امنیت پرهیز دارد.
صفحه رسمی Lynis و مخزن پروژه مرجع شناخت نسخه متن‌باز و دریافت کد هستند. امکانات و خدمات سازمانی را نباید بدون بررسی به نسخه جامعه نسبت داد. برای شروع، یک میزبان نماینده، یک گزارش پایه و چند تغییر قابل بازگشت کافی است. ارزش ابزار زمانی بیشتر می‌شود که چرخه مشاهده، تصمیم، اصلاح و آزمون دوباره به عادت عملیات تبدیل شود. در آن صورت ممیزی از یک رویداد مناسبتی به منبع شواهد برای نگهداری امن سیستم تبدیل خواهد شد.
برای تیمی که چند مدیر سیستم دارد، یک جلسه کوتاه مرور یافته‌ها بسیار مؤثر است. هر مدیر می‌تواند اثر تغییر پیشنهادی را بر سرویس خود توضیح دهد و وابستگی‌های پنهان را آشکار کند. خروجی جلسه باید چند اقدام با مسئول و زمان باشد، نه صرفاً تأیید دریافت گزارش. در اجرای بعدی، همان اقدامات با شواهد بررسی شوند. این چرخه به مرور دانش عملیاتی را ثبت می‌کند و وابستگی به حافظه یک فرد را کاهش می‌دهد، به‌خصوص هنگام جابه‌جایی مسئولیت یا اضافه شدن اعضای تازه به تیم.
