شکار Persistence در لینوکس؛ Systemd، Cron و Shell Startup

مفاهیم پایه و تکنیک‌های Persistence در لینوکس

در حوزه امنیت سایبری، Persistence به مجموعه اقداماتی گفته می‌شود که مهاجم برای حفظ دسترسی به یک سیستم پس از راه‌اندازی مجدد، تغییر وضعیت کاربر یا قطع ارتباط اولیه انجام می‌دهد. در لینوکس، این اقدامات معمولاً از طریق سوءاستفاده از سازوکارهای سیستمی مشروع مانند Systemd، Cron و فایل‌های راه‌اندازی شل صورت می‌گیرد. در چارچوب MITRE ATT&CK، این تکنیک‌ها عمدتاً در دو دسته T1547 (Boot or Logon Autostart Execution) و T1053 (Scheduled Task/Job) طبقه‌بندی می‌شوند. تکنیک T1547 به تنظیمات سیستمی اشاره دارد که برنامه‌ها را به‌صورت خودکار هنگام بوت یا ورود کاربر اجرا می‌کنند؛ در لینوکس، این شامل فایل‌های unit سرویس Systemd، اسکریپت‌های موجود در دایرکتوری‌هایی مانند /etc/init.d و همچنین فایل‌های راه‌اندازی شل مانند .bashrc، .profile و .zshrc می‌شود.

تکنیک T1053 نیز بر سوءاستفاده از قابلیت زمان‌بندی وظایف برای اجرای مکرر یا اولیه کد مخرب تمرکز دارد. زیرتکنیک T1053.003 مربوط به Cron است که در آن مهاجم با افزودن وظایف به crontab کاربر یا فایل‌های موجود در دایرکتوری‌هایی مانند /etc/cron.d، /etc/cron.hourly و مشابه آن، اجرای دوره‌ای کد خود را تضمین می‌کند. زیرتکنیک T1053.006 نیز به Systemd Timers اشاره دارد که جایگزین مدرن‌تری برای Cron محسوب می‌شود و امکان تعریف زمان‌بندی‌های پیچیده‌تر را فراهم می‌کند. مهاجم می‌تواند با ایجاد فایل‌های .timer و .service مرتبط در مسیرهایی مانند /etc/systemd/system یا /usr/lib/systemd/system، اجرای پایدار کد خود را در بازه‌های زمانی مشخص یا هنگام رویدادهای خاص سیستمی برنامه‌ریزی کند.

درک این نکته ضروری است که هرچند این تکنیک‌ها در دسته‌بندی MITRE به‌عنوان روش‌های Persistence و Privilege Escalation شناخته می‌شوند، اما سوءاستفاده از آنها معمولاً نیازمند دسترسی اولیه به سیستم است. بنابراین، تمرکز اصلی تحلیل‌گران امنیتی باید بر شناسایی تغییرات غیرعادی در این سازوکارها باشد، نه صرفاً وجود آنها. به‌عنوان مثال، وجود یک سرویس Systemd جدید که توسط کاربر غیرمجاز ایجاد شده یا یک cron job با بازه زمانی غیرمعمول، می‌تواند نشانه‌ای از فعالیت مخرب باشد. در بخش‌های بعدی، به شواهد و تله‌متری‌های قابل جمع‌آوری برای شناسایی این فعالیت‌ها خواهیم پرداخت.

• تکنیک T1547 در لینوکس شامل سوءاستفاده از Systemd service units، اسکریپت‌های /etc/init.d و فایل‌های راه‌اندازی شل است.
• تکنیک T1053.003 (Cron) به افزودن وظایف زمان‌بندی شده در crontab یا دایرکتوری‌های cron اشاره دارد.
• تکنیک T1053.006 (Systemd Timers) امکان زمان‌بندی دقیق‌تر و انعطاف‌پذیرتر را فراهم می‌کند و مهاجمان از آن برای اجرای دوره‌ای کد استفاده می‌کنند.
• هر دو تکنیک می‌توانند برای حفظ دسترسی (Persistence) و افزایش امتیاز (Privilege Escalation) مورد سوءاستفاده قرار گیرند.

شواهد و تله‌متری‌های قابل جمع‌آوری

برای شناسایی فعالیت‌های Persistence در لینوکس، جمع‌آوری و تحلیل شواهد از منابع مختلف ضروری است. بر اساس اطلاعات موجود در MITRE ATT&CK، یکی از مهم‌ترین منابع داده‌ای، رویدادهای مربوط به ایجاد یا تغییر فایل‌های پیکربندی Systemd است. این فایل‌ها معمولاً در مسیرهایی مانند /etc/systemd/system یا /usr/lib/systemd/system قرار دارند و هرگونه تغییر در آنها، به‌ویژه ایجاد فایل‌های .service یا .timer جدید، می‌تواند نشانه‌ای از فعالیت مخرب باشد. همچنین، تغییر در فایل‌های اسکریپت موجود در /etc/init.d نیز باید به‌عنوان یک رویداد مهم در نظر گرفته شود. تحلیل‌گران می‌توانند با پایش این مسیرها و ثبت هش‌های فایل، تغییرات غیرمجاز را شناسایی کنند.

دومین منبع حیاتی، cron jobs هستند. ایجاد یا تغییر cron jobs از طریق دستور crontab یا افزودن فایل‌های جدید به دایرکتوری‌هایی مانند /etc/cron.d، /etc/cron.hourly، /etc/cron.daily و مشابه آن، باید به‌دقت ثبت و بررسی شود. در محیط‌های کانتینری، استفاده غیرعادی از cron یا حلقه‌های sleep برای اجرای مکرر اسکریپت‌های ناشناخته نیز می‌تواند نشانه‌ای از فعالیت مخرب باشد. علاوه بر این، تغییر در فایل‌های راه‌اندازی شل مانند .bashrc، .profile، .bash_profile و .zshrc کاربران، به‌ویژه اگر حاوی دستورات مشکوک باشند، باید به‌عنوان یک رویداد امنیتی در نظر گرفته شود.

برای جمع‌آوری مؤثر این شواهد، پیشنهاد می‌شود از ابزارهای مانیتورینگ یکپارچگی فایل (FIM) استفاده شود که قادر به ثبت تغییرات در مسیرهای حساس هستند. همچنین، فعال‌سازی logging مناسب برای cron و systemd (مانند journald) می‌تواند به تحلیل‌گران در بازسازی توالی رویدادها کمک کند. لازم به ذکر است که برخی از این شواهد ممکن است به‌سرعت پاک شوند یا توسط مهاجم دستکاری شوند؛ بنابراین، جمع‌آوری به‌موقع و نگهداری امن لاگ‌ها از اهمیت بالایی برخوردار است. در نهایت، توصیه می‌شود که تحلیل‌گران از ترکیب چند منبع داده‌ای (مثلاً ارتباط بین ایجاد یک فایل systemd و اجرای یک فرآیند غیرعادی) برای افزایش دقت تشخیص استفاده کنند.

• ایجاد یا تغییر فایل‌های unit سرویس Systemd در مسیرهایی مانند /etc/systemd/system و /usr/lib/systemd/system
• تغییر در اسکریپت‌های /etc/init.d
• افزودن cron jobs از طریق crontab یا فایل‌های موجود در دایرکتوری‌های /etc/cron.*
• تغییر در فایل‌های راه‌اندازی شل مانند .bashrc، .profile و .zshrc
• استفاده غیرعادی از cron یا حلقه‌های sleep در محیط‌های کانتینری

1. پیکربندی ابزارهای FIM برای پایش مسیرهای حساس مانند /etc/systemd/system و /etc/cron.d
2. فعال‌سازی logging برای systemd (journald) و cron (syslog) و نگهداری امن لاگ‌ها
3. بررسی دوره‌ای cron jobs موجود در سیستم و مقایسه با baseline اولیه
4. توجه به تغییرات فایل‌های راه‌اندازی شل کاربران، به‌ویژه کاربران دارای امتیاز بالا

روند کار (Workflow) برای شناسایی و پاسخ

برای شناسایی و پاسخ به تهدیدات Persistence در لینوکس، ابتدا باید یک تصویر پایه از وضعیت عادی سیستم تهیه شود. این تصویر شامل فهرست واحدهای systemd فعال، محتوای crontab کاربران و فایل‌های موجود در مسیرهای startup مانند /etc/profile.d و ~/.bashrc است. توصیه می‌شود این تصویر به‌صورت دوره‌ای (مثلاً هفتگی) به‌روزرسانی شود تا تغییرات غیرعادی سریع‌تر قابل تشخیص باشند. در گام بعد، هرگونه تغییر در این فایل‌ها باید با استفاده از ابزارهای مانیتورینگ یکپارچگی فایل (مانند AIDE یا auditd) ثبت و هشدار داده شود.

هنگامی که یک هشدار مبنی بر تغییر در فایل‌های systemd، cron یا startup دریافت شد، فرآیند triage آغاز می‌شود. ابتدا باید مشخص شود که آیا تغییر توسط یک کاربر مجاز (مثلاً مدیر سیستم) انجام شده است یا خیر. برای این کار، لاگ‌های احراز هویت (مانند /var/log/auth.log) و تاریخچه دستورات کاربران بررسی می‌شود. در صورت تأیید غیرمجاز بودن تغییر، باید فایل‌های تغییر یافته به‌صورت ایزوله (مثلاً در یک محیط sandbox) تحلیل شوند. تحلیل محتوا شامل بررسی دستورات اجرایی، مسیرهای باینری، و هرگونه ارتباط شبکه‌ای است که ممکن است نشان‌دهنده رفتار مخرب باشد.

پس از تحلیل، مرحله پاسخ آغاز می‌شود. این مرحله شامل حذف یا غیرفعال‌سازی مکانیزم Persistence (مثلاً غیرفعال کردن سرویس systemd یا حذف cron job) و همچنین بازیابی فایل‌های تغییر یافته از نسخه پشتیبان است. در ادامه، باید جستجوی جامعی برای یافتن سایر نشانه‌های نفوذ (مانند باینری‌های غیرعادی یا اتصالات شبکه مشکوک) انجام شود. در نهایت، تمام اقدامات انجام‌شده مستند شده و توصیه‌هایی برای بهبود امنیت (مانند محدود کردن دسترسی به فایل‌های حساس) ارائه می‌شود. این روند باید به‌صورت چرخه‌ای تکرار شود تا از پاکسازی کامل اطمینان حاصل شود.

• گام‌های پیشنهادی برای شناسایی:
• ۱. تهیه تصویر پایه از واحدهای systemd، cron و فایل‌های startup.
• ۲. فعال‌سازی مانیتورینگ یکپارچگی فایل بر روی مسیرهای حساس.
• ۳. بررسی دوره‌ای لاگ‌های احراز هویت و دسترسی به فایل‌ها.
• ۴. تحلیل هرگونه تغییر غیرعادی در محیط ایزوله.

1. ۱. اجرای دستور systemctl list-unit-files --type=service برای فهرست سرویس‌های systemd.
2. ۲. بررسی crontab -l برای هر کاربر و همچنین فایل‌های /etc/cron*.
3. ۳. بازبینی فایل‌های /etc/profile.d و ~/.bashrc برای یافتن دستورات مشکوک.
4. ۴. در صورت مشاهده تغییر، نمونه‌برداری از فایل و تحلیل محتوا با ابزارهایی مانند strings و ldd.

systemctl list-unit-files --type=service | grep enabled
crontab -l
cat /etc/cron.d/*

راهنمای Triage و اولویت‌بندی هشدارها

اولویت‌بندی هشدارهای مرتبط با Persistence در لینوکس باید بر اساس معیارهای مشخصی انجام شود که شامل سطح دسترسی کاربر درگیر، نوع مکانیزم مورد استفاده، و میزان انحراف از رفتار عادی است. هشدارهایی که مربوط به تغییرات در فایل‌های systemd یا cron توسط کاربران غیرمجاز (مانند کاربران بدون نقش مدیریتی) هستند، باید در بالاترین اولویت قرار گیرند. همچنین، تغییراتی که در فایل‌های startup با محتوای مبهم (مانند دستورات رمزنگاری‌شده یا باینری‌های ناشناخته) انجام می‌شود، نیاز به بررسی فوری دارند.

برای triage مؤثر، پیشنهاد می‌شود یک سیستم امتیازدهی طراحی شود که به هر هشدار بر اساس عواملی مانند شدت تهدید، میزان دسترسی کاربر، و تعداد سیستم‌های درگیر، امتیاز دهد. به عنوان مثال، تغییر در یک سرویس systemd که با امتیازات root اجرا می‌شود، امتیاز بالاتری نسبت به تغییر در crontab یک کاربر معمولی دارد. همچنین، هشدارهایی که با سایر نشانه‌های نفوذ (مانند افزایش ترافیک شبکه یا ایجاد فایل‌های جدید در دایرکتوری‌های حساس) هم‌زمان هستند، باید در اولویت بالاتری قرار گیرند.

در فرآیند triage، باید از منابع معتبر مانند MITRE ATT&CK برای درک تکنیک‌های مرتبط استفاده شود. به عنوان مثال، تکنیک T1547 (اجرای خودکار در هنگام بوت یا ورود) و T1053 (زمان‌بندی وظایف) به‌طور مستقیم با این موضوع مرتبط هستند. توصیه می‌شود که تحلیلگران با زیرتکنیک‌های مرتبط مانند T1547.006 (ماژول‌های هسته) و T1053.003 (cron) آشنا باشند. در نهایت، هر هشدار باید بر اساس شواهد موجود (مانند محتوای فایل‌ها و لاگ‌ها) تأیید یا رد شود و از اقدامات حدسی خودداری گردد.

• معیارهای اولویت‌بندی:
• ۱. سطح دسترسی کاربر (root در مقابل کاربر عادی).
• ۲. نوع مکانیزم (systemd در مقابل cron).
• ۳. وجود محتوای مشکوک (مانند دستورات obfuscated).
• ۴. هم‌زمانی با سایر نشانه‌های نفوذ.

1. ۱. بررسی هویت کاربری که تغییر را انجام داده است.
2. ۲. ارزیابی حساسیت فایل تغییر یافته (مثلاً سرویس‌های حیاتی).
3. ۳. جستجو برای الگوهای شناخته‌شده در محتوای فایل.
4. ۴. ارجاع به پایگاه‌های اطلاعاتی تهدید برای تطبیق با تکنیک‌های شناخته‌شده.

stat -c '%U %n' /etc/systemd/system/*.service
journalctl -u suspicious.service --since '1 hour ago'

مثبت‌های کاذب و چالش‌های تشخیص

در تشخیص نفوذ در محیط‌های لینوکسی، یکی از دشوارترین جنبه‌ها، تمایز بین فعالیت‌های مخرب و رفتارهای مشروع مدیران سیستم است. تکنیک‌های Persistence مبتنی بر systemd، cron و فایل‌های startup به دلیل استفاده گسترده و روزمره از این مکانیزم‌ها در مدیریت سرویس‌ها و زمان‌بندی وظایف، به‌طور ذاتی مستعد ایجاد هشدارهای اشتباه هستند. به عنوان مثال، یک مدیر سیستم ممکن است به‌طور عمدی یک سرویس systemd برای اجرای خودکار یک برنامه کاربردی خاص ایجاد کند، یا یک cron job برای پشتیبان‌گیری دوره‌ای تنظیم نماید. این اقدامات مشروع، از نظر شکلی با الگوهای نفوذ یکسان هستند و بدون تحلیل زمینه‌ای دقیق، تشخیص‌دهنده‌ها به راحتی آن‌ها را به عنوان تهدید طبقه‌بندی می‌کنند.

منابع MITRE ATT&CK به صراحت اشاره می‌کنند که سوءاستفاده از این ویژگی‌های سیستمی، مبتنی بر بهره‌برداری از قابلیت‌های استاندارد است و بنابراین نمی‌توان آن را با کنترل‌های پیشگیرانه ساده مهار کرد. این بدان معناست که تیم‌های دفاعی باید به جای تکیه بر بلوک‌کردن، بر روی تشخیص رفتاری و تحلیل زمینه‌ای تمرکز کنند. چالش اصلی در این است که یک cron job مخرب ممکن است از نظر ساختار دقیقاً مشابه یک cron job مشروع باشد؛ تفاوت در محتوای دستور، زمان‌بندی غیرعادی، یا ارتباط آن با فرآیندهای دیگر است. به همین ترتیب، یک فایل سرویس systemd که توسط مهاجم ایجاد شده، ممکن است نامی مشابه با سرویس‌های استاندارد داشته باشد یا در دایرکتوری‌های قابل نوشتن توسط کاربران غیرمجاز قرار گیرد.

برای کاهش مثبت‌های کاذب، لازم است که سیستم‌های تشخیصی از یک رویکرد چندلایه استفاده کنند. به عنوان مثال، به‌جای هشدار برای هر تغییر در فایل‌های cron یا systemd، باید تغییرات را با رفتارهای بعدی مانند اجرای فرآیندهای غیرعادی، اتصالات شبکه مشکوک، یا دسترسی به فایل‌های حساس مرتبط کرد. همچنین، ایجاد یک خط مبنا (baseline) از فعالیت‌های عادی هر سیستم، به تحلیلگران کمک می‌کند تا انحرافات را شناسایی کنند. استفاده از ابزارهای auditd و نظارت بر تغییرات فایل‌های پیکربندی، همراه با ثبت لاگ‌های اجرای فرآیندها، می‌تواند زمینه را برای تشخیص دقیق‌تر فراهم کند. در نهایت، آموزش تیم‌های عملیاتی برای تشخیص تفاوت بین یک اسکریپت مخرب و یک اسکریپت مدیریتی، نقش مهمی در کاهش نویز هشدارها دارد.

• استفاده مشروع از cron برای پشتیبان‌گیری یا به‌روزرسانی خودکار، شایع‌ترین منبع مثبت کاذب است.
• سرویس‌های systemd که توسط مدیران برای اجرای برنامه‌های کاربردی وب یا پایگاه داده ایجاد می‌شوند، ممکن است با الگوهای مخرب اشتباه گرفته شوند.
• فایل‌های startup در پوسته‌های مختلف (مانند .bashrc یا .profile) اغلب توسط کاربران برای تنظیم محیط خود تغییر می‌کنند و این تغییرات می‌توانند هشدار ایجاد کنند.

1. ایجاد یک خط مبنا از cron jobs و سرویس‌های systemd فعال در هر سیستم.
2. استفاده از ابزارهای نظارت بر یکپارچگی فایل (مانند AIDE) برای شناسایی تغییرات غیرمجاز.
3. همبستگی هشدارها با رویدادهای بعدی مانند اجرای فرآیندهای غیرعادی یا اتصالات شبکه مشکوک.

auditctl -w /etc/crontab -p wa -k cron_change

محدودیت‌های تکنیک‌های تشخیص

تکنیک‌های تشخیصی موجود برای شناسایی Persistence در لینوکس، با محدودیت‌های ذاتی مواجه هستند که عمدتاً ناشی از ماهیت باز و انعطاف‌پذیر این سیستم‌عامل است. منابع MITRE نشان می‌دهند که برخی زیرتکنیک‌ها مانند Systemd Timers (T1053.006) یا Cron (T1053.003) ممکن است به‌طور کامل توسط ابزارهای تشخیصی استاندارد پوشش داده نشوند. به عنوان مثال، بسیاری از ابزارهای امنیتی بر روی فایل‌های متعارف مانند /etc/crontab تمرکز دارند، اما مهاجمان می‌توانند از دایرکتوری‌های /etc/cron.d یا /var/spool/cron/crontabs استفاده کنند که ممکن است از دید این ابزارها پنهان بمانند. همچنین، systemd اجازه ایجاد تایمرهای پیچیده با گزینه‌های دقیق را می‌دهد که تشخیص آن‌ها بدون تحلیل عمیق محتوای فایل‌های واحد (unit files) دشوار است.

یکی دیگر از محدودیت‌های مهم، نیاز به دسترسی‌های خاص برای جمع‌آوری شواهد است. برای مشاهده کامل تمام cron jobs و سرویس‌های systemd، معمولاً به دسترسی ریشه (root) نیاز است. در محیط‌هایی که اصل کمترین امتیاز (least privilege) رعایت می‌شود، ابزارهای تشخیصی ممکن است نتوانند به تمام اطلاعات لازم دسترسی پیدا کنند. به عنوان مثال، یک عامل نظارتی که با حساب کاربری غیرممتاز اجرا می‌شود، ممکن است نتوانند محتوای فایل‌های پیکربندی را در دایرکتوری‌های محافظت‌شده بخوانند. این محدودیت می‌تواند منجر به نابینایی در برابر حملاتی شود که از این مسیرها انجام می‌شوند. علاوه بر این، برخی تکنیک‌های تشخیصی مبتنی بر رفتار، ممکن است به دلیل پیچیدگی محیط‌های مدرن لینوکس (مانند کانتینرها) دقت کافی نداشته باشند.

برای غلبه بر این محدودیت‌ها، پیشنهاد می‌شود که سازمان‌ها از ترکیبی از روش‌های تشخیصی استفاده کنند. به عنوان مثال، علاوه بر نظارت بر فایل‌های پیکربندی، باید از ابزارهای رفتاری مانند eBPF برای مشاهده اجرای فرآیندها و فراخوانی‌های سیستمی استفاده شود. همچنین، جمع‌آوری لاگ‌ها از منابع مختلف (مانند journald و syslog) و ارسال آن‌ها به یک SIEM مرکزی، می‌تواند به تحلیلگران کمک کند تا الگوهای مشکوک را در مقیاس بزرگ شناسایی کنند. با این حال، باید توجه داشت که هیچ روش تشخیصی کاملی وجود ندارد و تیم‌های دفاعی باید به‌طور مداوم فرضیات خود را بازبینی کنند. در نهایت، توصیه می‌شود که از تکنیک‌های تشخیصی به عنوان یک لایه از دفاع در عمق استفاده شود و نه به عنوان تنها راه‌حل.

• پوشش ناقص زیرتکنیک‌ها: ابزارهای تشخیصی ممکن است فقط برخی از مکان‌های cron یا systemd را پوشش دهند.
• نیاز به دسترسی ریشه برای جمع‌آوری کامل شواهد، که در محیط‌های کم‌امتیاز ممکن است برآورده نشود.
• پیچیدگی محیط‌های کانتینری که تشخیص را دشوارتر می‌کند.

1. استفاده از ترکیبی از نظارت بر فایل‌ها و ابزارهای رفتاری مانند eBPF.
2. متمرکزسازی لاگ‌ها در یک SIEM برای تحلیل جامع‌تر.
3. بازبینی دوره‌ای فرضیات تشخیصی و به‌روزرسانی قوانین بر اساس تهدیدات جدید.

systemctl list-timers --all

شاخص‌های کلیدی عملکرد (KPIs) و معیارهای اثربخشی

برای ارزیابی دقیق توانمندی تشخیص و پاسخ به تکنیک‌های Persistence در لینوکس، تعریف شاخص‌های کلیدی عملکرد (KPI) ضروری است. این شاخص‌ها باید بر اساس شواهد قابل اندازه‌گیری از محیط عملیاتی طراحی شوند و نه صرفاً بر اساس حدس یا تجربه‌های ذهنی. معیارهای پیشنهادی شامل تعداد هشدارهای معتبر تولیدشده در بازه زمانی مشخص، نرخ مثبت کاذب، زمان متوسط تشخیص (MTTD) و زمان متوسط پاسخ (MTTR) است. همچنین پوشش تکنیک‌های مرتبط با Persistence مانند T1547 (اجرای خودکار هنگام بوت یا ورود) و T1053 (زمان‌بندی وظایف) باید به‌صورت دوره‌ای سنجیده شود.

برای هر KPI باید آستانه‌های قابل قبول تعریف شود. برای نمونه، نرخ مثبت کاذب در هشدارهای مرتبط با تغییر فایل‌های systemd یا cron نباید از ۵ درصد تجاوز کند، زیرا هشدارهای زیاد باعث خستگی تحلیلگر و نادیده‌گرفتن رویدادهای واقعی می‌شود. زمان پاسخ به یک هشدار معتبر باید کمتر از ۱۵ دقیقه باشد، به‌ویژه برای سیستم‌های حساس. همچنین درصد پوشش تکنیک‌های شناسایی‌شده نسبت به ماتریس MITRE باید حداقل ۸۰ درصد باشد. این معیارها باید به‌صورت خودکار از ابزارهای SIEM یا EDR استخراج شوند و در داشبورد مدیریتی قابل مشاهده باشند.

توجه به این نکته ضروری است که معیارهای اثربخشی باید با توجه به ریسک‌پذیری سازمان و اهمیت دارایی‌ها تنظیم شوند. برای مثال، در محیط‌های با سطح حساسیت بالا، آستانه‌های سخت‌گیرانه‌تری اعمال می‌شود. همچنین باید بین معیارهای کمی (مانند تعداد رویدادها) و کیفی (مانند دقت تحلیل) توازن برقرار شود. پیشنهاد می‌شود که ارزیابی دوره‌ای (ماهانه یا فصلی) انجام شود و نتایج با سناریوهای حمله شبیه‌سازی‌شده (مانند اجرای یک بک‌دور فرضی از طریق cron) اعتبارسنجی گردد. این فرآیند باید مستند و قابل بازبینی باشد.

• تعداد هشدارهای معتبر مرتبط با تغییر فایل‌های systemd، cron و فایل‌های راه‌اندازی شل در هر ماه.
• نرخ مثبت کاذب (FPR) برای هر نوع هشدار، به‌صورت درصدی از کل هشدارها.
• زمان متوسط تشخیص (MTTD) از لحظه ایجاد تغییر مخرب تا صدور هشدار.
• زمان متوسط پاسخ (MTTR) از صدور هشدار تا مهار کامل تهدید.
• درصد پوشش تکنیک‌های T1547 و T1053 در قوانین تشخیصی نسبت به ماتریس MITRE.

1. استخراج خودکار معیارها از SIEM یا ابزارهای مانیتورینگ با استفاده از کوئری‌های استاندارد.
2. تعیین آستانه‌های اولیه بر اساس baseline محیط و تنظیم آن‌ها پس از هر دوره ارزیابی.
3. مستندسازی هر رویداد تشخیص‌داده‌شده و مقایسه آن با معیارهای تعیین‌شده.
4. برگزاری جلسات بازبینی دوره‌ای با تیم امنیتی برای تحلیل انحراف از آستانه‌ها.

عملیاتی‌سازی و بهبود مستمر

برای عملیاتی‌سازی فرآیندهای تشخیص و پاسخ به Persistence در لینوکس، باید یک چرخه بهبود مستمر مبتنی بر چارچوب MITRE ATT&CK ایجاد شود. این چرخه شامل شناسایی شکاف‌ها در پوشش تکنیک‌ها، به‌روزرسانی منظم قوانین تشخیصی، و هماهنگی نزدیک با تیم‌های امنیتی (SOC، تیم پاسخ به حادثه، و تیم زیرساخت) است. به‌عنوان مثال، برای تکنیک T1547 (اجرای خودکار هنگام بوت) باید قوانینی برای پایش تغییرات در فایل‌های systemd (مانند /etc/systemd/system) و دایرکتوری‌های autostart (مانند ~/.config/autostart) ایجاد شود. برای T1053 (زمان‌بندی وظایف) نیز باید تغییرات در crontab و systemd timerها به‌صورت بلادرنگ رصد شود.

بهبود مستمر مستلزم به‌روزرسانی منظم قوانین تشخیصی بر اساس تهدیدات جدید و بازخورد حوادث گذشته است. پیشنهاد می‌شود که یک فرآیند بازبینی ماهانه برای قوانین SIEM و YARA (در صورت استفاده) تعریف شود. همچنین باید از شواهد موجود مانند گزارش‌های تحلیل بدافزار و CTI (تهدید هوشمند) برای اصلاح قوانین استفاده شود. برای مثال، اگر مشاهده شود که مهاجمان از فایل‌های پیکربندی systemd با نام‌های غیرعادی استفاده می‌کنند، باید قوانین تشخیصی برای شناسایی الگوهای نام‌گذاری غیرمعمول به‌روزرسانی شود. این فرآیند باید مستند باشد و مسئولیت آن به‌وضوح مشخص شود.

هماهنگی با تیم‌های امنیتی باید شامل جلسات منظم (مثلاً هفتگی) برای مرور هشدارهای جدید، تحلیل شکاف‌ها، و تصمیم‌گیری درباره تغییرات در زیرساخت باشد. همچنین باید یک playbook پاسخ به حادثه برای سناریوهای Persistence تدوین شود که شامل مراحل شناسایی، مهار، ریشه‌یابی، و بازیابی است. این playbook باید بر اساس تکنیک‌های MITRE و با در نظر گرفتن محدودیت‌های محیط (مانند سیستم‌های legacy) طراحی شود. در نهایت، آموزش مستمر تحلیلگران در مورد تکنیک‌های جدید Persistence و نحوه استفاده از ابزارهای تشخیصی (مانند auditd، osquery، و systemd-analyze) ضروری است. این آموزش‌ها باید با تمرین‌های عملی (مانند شبیه‌سازی حمله) همراه باشد تا اثربخشی آن سنجیده شود.

• ایجاد یک چرخه بازبینی ماهانه برای قوانین تشخیصی بر اساس بازخورد حوادث و CTI.
• استفاده از ابزارهای متن‌باز مانند auditd و osquery برای جمع‌آوری شواهد و تشخیص ناهنجاری‌ها.
• تدوین playbook پاسخ به حادثه برای سناریوهای Persistence با مراحل مشخص.
• برگزاری تمرین‌های شبیه‌سازی حمله (Red Team) به‌صورت دوره‌ای برای ارزیابی آمادگی تیم.
• مستندسازی تمام تغییرات در قوانین و فرآیندها برای قابلیت ردیابی.

1. برگزاری جلسه هماهنگی اولیه با تیم‌های امنیتی برای تعیین نقش‌ها و مسئولیت‌ها.
2. پیاده‌سازی قوانین تشخیصی پایه برای T1547 و T1053 با استفاده از ابزارهای موجود.
3. راه‌اندازی یک داشبورد مشترک برای نمایش هشدارها و معیارهای کلیدی.
4. انجام یک شبیه‌سازی حمله کنترل‌شده (مثلاً ایجاد یک cron job مخرب) و ارزیابی عملکرد تیم.
5. بازبینی نتایج شبیه‌سازی و به‌روزرسانی قوانین و playbook بر اساس یافته‌ها.