OpenSCAP چه چیزی را ارزیابی می‌کند؟
OpenSCAP مجموعه‌ای متن‌باز برای کار با محتوای استاندارد ارزیابی امنیتی است. ابزار خط فرمان آن، oscap، می‌تواند محتوای پشتیبانی‌شده را پردازش و سیستم را بر اساس آن ارزیابی کند. تفاوت مهم این رویکرد با یک فهرست دستی آن است که سیاست و منطق بسیاری از آزمون‌ها در قالب ماشین‌خوان توصیف می‌شوند. این امکان به تکرار ارزیابی و تولید شواهد کمک می‌کند. با این حال کیفیت نتیجه به مناسب بودن محتوا برای سیستم مورد نظر وابسته است. اجرای یک ابزار درست با پروفایل نامناسب، نتیجه قابل اتکا درباره انطباق میزبان ایجاد نمی‌کند.
معرفی رسمی OpenSCAP Base میان کتابخانه و ابزار خط فرمان تمایز می‌گذارد. موتور ارزیابی را باید از محتوای سیاست جدا دانست. بسته محتوای امنیتی تعیین می‌کند کدام قواعد و برای چه محصولی بررسی شوند؛ موتور آن قواعد را اجرا یا پردازش می‌کند. بنابراین نصب OpenSCAP به تنهایی به معنای داشتن همه سیاست‌های مناسب نیست. در طراحی ممیزی، نسخه موتور، نسخه محتوا، شناسه پروفایل و مشخصات سیستم همگی باید ثبت شوند تا نتیجه قابل بازتولید باشد.
استانداردها را به اندازه نیاز بشناسید
در اکوسیستم SCAP با نام‌هایی مانند XCCDF و OVAL روبه‌رو می‌شوید. برای استفاده عملی لازم نیست همه جزئیات آن‌ها را حفظ کنید، اما باید نقش کلی را بفهمید: بخشی از محتوا ساختار سیاست و قواعد را توصیف می‌کند و بخشی منطق بررسی وضعیت را بیان می‌کند. این جداسازی باعث می‌شود یک گزارش شامل هم نتیجه آزمون و هم زمینه سیاست باشد. در عیب‌یابی، دانستن اینکه مشکل در انتخاب پروفایل، محتوای آزمون یا اجرای موتور است زمان زیادی صرفه‌جویی می‌کند.
شناسه قاعده را در کارهای اصلاح نگه دارید. عنوان انسانی ممکن است در نسخه جدید تغییر کند یا چند قاعده عنوان مشابه داشته باشند. شناسه کمک می‌کند نتیجه گزارش، وظیفه اصلاح و تصمیم استثنا به یک موضوع مشخص اشاره کنند. البته شناسه نیز باید همراه نسخه محتوا ثبت شود، زیرا معنا و جزئیات آزمون ممکن است به مرور اصلاح شوند. گزارش قابل دفاع فقط یک تصویر از درصد موفقیت نیست؛ مجموعه‌ای از اطلاعات است که نشان می‌دهد چه سیاستی، روی کدام سیستم و با چه روش اجرا شده است.
انتخاب محتوای متناسب با سیستم
انتخاب را از محصول و نسخه واقعی سیستم‌عامل آغاز کنید. محتوایی که برای توزیع یا انتشار دیگری ساخته شده ممکن است مسیر فایل، نام بسته یا تنظیمات متفاوتی انتظار داشته باشد. نتیجه‌های نامرتبط یا غیرقابل اعمال را با شکست امنیتی یکسان نگیرید. ابتدا سازگاری محتوا را بررسی کنید و سپس پروفایل مناسب نقش میزبان را انتخاب نمایید. استفاده از پروفایلی با نام سخت‌گیرانه‌تر لزوماً انتخاب بهتر نیست؛ بعضی کنترل‌ها برای محیط یا مأموریت خاص طراحی شده‌اند و باید با نیاز واقعی سازمان تطبیق داده شوند.
برای یک میزبان پایگاه داده، نیاز دسترسی برنامه، سیاست ثبت رویداد و روش پشتیبان‌گیری ممکن است با ایستگاه کاری متفاوت باشد. اگر پروفایل انتخابی این تفاوت را منعکس نمی‌کند، باید فرایند سفارشی‌سازی و استثنا روشن باشد. هدف آن نیست که نتیجه دلخواه را با حذف قواعد بسازید؛ هدف تدوین سیاستی است که هم قابل اجرا و هم قابل دفاع باشد. هر تغییر باید دلیل داشته باشد و معلوم کند کنترل اصلی چگونه برآورده می‌شود یا چرا موقتاً پذیرفته نشده است.
ارزیابی نخست بدون اصلاح خودکار
در شروع، فقط ارزیابی و گزارش‌گیری انجام دهید. این مرحله به شما اجازه می‌دهد حجم یافته‌ها، زمان اجرا و نقاط ناسازگاری را ببینید. فعال کردن اصلاح خودکار پیش از فهم قواعد می‌تواند دسترسی یا کارکرد سرویس را تغییر دهد. یک ماشین آزمایش یا نسخه نماینده از میزبان انتخاب کنید و وضعیت اولیه را ثبت نمایید. اگر از محیط شبیه‌سازی‌شده استفاده می‌کنید، تفاوت آن با تولید را نیز بنویسید؛ نبود یک سرویس در آزمایش ممکن است نتیجه‌ای بسازد که در میزبان اصلی معتبر نباشد.
گزارش انسانی برای مرور مفید است و خروجی ساختاریافته برای مقایسه و بایگانی ارزش دارد. هر دو باید به یک اجرای مشخص متصل باشند. نام‌گذاری فایل‌ها بر اساس میزبان، زمان و پروفایل از جابه‌جایی شواهد جلوگیری می‌کند. همچنین خطاهای اجرای ابزار را از نتایج سیاست جدا کنید. اگر آزمون به دلیل کمبود دسترسی اجرا نشده، نباید آن را معادل قبولی یا شکست قطعی کنترل دانست. این تفکیک به‌خصوص در گزارش‌های مدیریتی اهمیت دارد، زیرا خلاصه‌سازی ممکن است وضعیت‌های متفاوت را در یک عدد ادغام کند.
تفسیر نتیجه و پیگیری علت
برای هر یافته، توضیح قاعده و شواهد اجرای آن را بخوانید. گاهی نتیجه از مقدار واقعی تنظیم ناشی می‌شود و گاهی از فرضی که محتوا درباره محیط دارد. پیش از تغییر، وضعیت را با روش مستقل و کم‌خطر بررسی کنید. این بررسی نباید به تکرار کورکورانه همان فرمان محدود شود؛ باید نشان دهد تنظیم مورد نظر در عمل چگونه بر سرویس اثر می‌گذارد. اگر نتیجه ابزار و مشاهده مدیر متفاوت است، اختلاف را مستند کنید و نسخه محتوا را بررسی نمایید.
وضعیت‌های غیرقابل اعمال، نامعلوم یا خطا را در گزارش نگه دارید. حذف آن‌ها از محاسبه بدون توضیح می‌تواند تصویری بیش از حد مثبت ایجاد کند. در مقابل شمردن همه آن‌ها به عنوان نقض سیاست نیز نادرست است. گزارش باید بگوید چه تعداد قاعده واقعاً ارزیابی شده، چه مواردی نیازمند بررسی بیشتر است و چه چیزهایی خارج از دامنه بوده‌اند. این شفافیت برای تصمیم اصلاح از یک درصد کلی مفیدتر است و امکان مقایسه منصفانه میان اجراها را فراهم می‌کند.
سفارشی‌سازی سیاست با ردپا
سفارشی‌سازی یا tailoring باید مانند تغییر یک سند کنترل‌شده مدیریت شود. مشخص کنید کدام قواعد انتخاب شده‌اند، کدام مقدارها تغییر کرده‌اند و چه کسی تصمیم را تأیید کرده است. فایل سفارشی‌سازی را همراه گزارش نگه دارید؛ بدون آن نتیجه بعداً قابل بازسازی نیست. تغییر مستقیم و پراکنده فایل‌های محتوای بالادستی می‌تواند ارتقا را دشوار کند و تشخیص تفاوت محلی را از بین ببرد. روش مستند و قابل نسخه‌بندی، امکان مقایسه با انتشارهای بعدی را حفظ می‌کند.
برای هر استثنا، تاریخ انقضا یا بازبینی تعیین کنید. مثلاً یک نرم‌افزار قدیمی ممکن است موقتاً با سیاست جدید سازگار نباشد. در این حالت فقط خاموش کردن آزمون کافی نیست؛ برنامه رفع وابستگی، مسئول و کنترل جبرانی باید مشخص شود. وقتی شرایط تغییر کرد، استثنا باید دوباره ارزیابی گردد. این کار کمک می‌کند سیاست به مرور به مجموعه‌ای از حذف‌ها تبدیل نشود. بازبینی استثناها بهتر است با تغییرات محصول و ارتقای سیستم‌عامل هم‌زمان شود تا تصمیم‌ها به واقعیت محیط نزدیک بمانند.
اصلاحات و خطر اجرای دسته‌جمعی
بعضی محتواها دستور یا متن اصلاح ارائه می‌کنند، اما وجود اصلاح آماده به معنای مناسب بودن اجرای فوری آن نیست. تغییر می‌تواند بر ورود کاربران، سرویس شبکه، مجوز فایل یا عملکرد برنامه اثر بگذارد. ابتدا متن اصلاح را بخوانید و پیش‌شرط‌ها را بررسی کنید. در محیط آزمایش، یک تغییر یا مجموعه کوچک مرتبط را اعمال کنید و سپس هم ارزیابی امنیتی و هم آزمون کارکرد سرویس را تکرار نمایید. موفق شدن قاعده پس از اصلاح، به تنهایی ثابت نمی‌کند برنامه همچنان درست کار می‌کند.
برنامه بازگشت باید پیش از تغییر آماده باشد. نسخه پشتیبان از پیکربندی، دسترسی جایگزین و روش بازگرداندن سرویس را مشخص کنید. اگر اصلاح مسیر ورود راه دور را تغییر می‌دهد، یک راه بازیابی مستقل لازم است. اجرای دسته‌جمعی روی همه میزبان‌ها، بدون نمونه اولیه، هزینه خطای محتوا یا فرض اشتباه را بزرگ می‌کند. استقرار تدریجی اجازه می‌دهد اثر واقعی دیده شود و پیش از گسترش، مشکل رفع گردد. این روش برای سیاست‌های سخت‌سازی نیز مانند انتشار نرم‌افزار مفید است.
استفاده در چرخه ساخت و تحویل
ارزیابی را می‌توان در ساخت تصویر پایه یا تحویل میزبان وارد کرد. در این حالت معیار پذیرش باید معلوم باشد: چه پروفایلی اجرا شود، چه وضعیت‌هایی مانع تحویل هستند و استثنا چگونه ثبت می‌شود. ذخیره گزارش در کنار شناسه تصویر کمک می‌کند نتیجه به خروجی مشخصی متصل بماند. اسکن تصویر قدیمی را نباید به ساخت جدید تعمیم داد. اگر در زمان استقرار تنظیمات مهم تغییر می‌کنند، ارزیابی پس از استقرار نیز لازم است تا وضعیت نهایی دیده شود.
برای سیستم‌های دارای داده حساس، محل نگهداری گزارش را کنترل کنید. خروجی ممکن است نام میزبان، مسیرها و جزئیات سیاست را نشان دهد. دسترسی حساب اجرای ممیزی نیز باید روشن باشد. بهتر است حساب و وظیفه‌ای مشخص برای ارزیابی وجود داشته باشد و استفاده از آن ثبت شود. ابزار ممیزی نباید بهانه‌ای برای توزیع گسترده دسترسی مدیریتی شود. اگر جمع‌آوری گزارش مرکزی است، مسیر انتقال و امکان تغییر گزارش در راه را نیز بررسی کنید تا شواهد قابل اعتماد باقی بمانند.
تکرارپذیری و مقایسه در طول زمان
هنگام ارتقای محتوا، تغییر نتیجه ممکن است از تغییر تعریف آزمون ناشی شود، نه از تغییر سیستم. برای فهم این تفاوت، ابتدا محتوای جدید را روی یک گروه محدود اجرا و اختلاف را تحلیل کنید. نگهداری نسخه قبلی محتوا و گزارش امکان بررسی دوباره را فراهم می‌کند. در گزارش روند، زمان تغییر سیاست را علامت بزنید تا بهبود یا افت ناگهانی با عملکرد تیم اشتباه نشود. مقایسه معتبر نیازمند زمینه ثابت یا توضیح روشن درباره تفاوت زمینه است.
سلامت خود فرایند ارزیابی را نیز بسنجید. میزبان بدون گزارش تازه، اجرای ناقص و خروجی غیرقابل خواندن باید هشدار ایجاد کنند. تنها شمارش فایل‌های گزارش کافی نیست؛ ممکن است فایل تولید شده باشد ولی آزمون‌ها به دلیل خطای ورودی انجام نشده باشند. معیار عملی می‌تواند شامل پایان موفق اجرا، ثبت پروفایل مورد انتظار و وجود نتایج قابل تفسیر باشد. بازبینی نمونه‌ای از گزارش‌ها توسط انسان کمک می‌کند خطای خلاصه‌ساز یا تغییر قالب خروجی زودتر دیده شود.
جایگاه درست در برنامه امنیت
OpenSCAP برای ارزیابی نظام‌مند سیاست‌های قابل بیان در محتوای پشتیبانی‌شده مفید است، اما گواه نبود همه خطرها نیست. نقص منطق برنامه، سرقت نشست یا دسترسی اشتباه در سرویس بیرونی ممکن است خارج از دامنه این ارزیابی باشد. نتیجه را با مدیریت وصله، پایش و ارزیابی معماری ترکیب کنید. پرتال رسمی OpenSCAP و مخزن پروژه نقطه شروع بررسی ابزار و مستندات هستند. ارزش اصلی در زنجیره روشن سیاست، آزمون، شواهد و اقدام است؛ زنجیره‌ای که فرد دیگری بتواند آن را بازبینی و با همان ورودی‌ها دوباره اجرا کند.
