چگونه یک برنامه پاسخ به حادثه تدوین کنید که واقعاً کار کند؟

اکثر سازمان‌ها در پاسخ به حادثه ناکام نمی‌شوند زیرا ابزار ندارند. آن‌ها ناکام می‌شوند زیرا هیچ‌کس پیش‌تر توافق نکرده که کی چه کار می‌کند، و اولین حادثه واقعی به جلسه‌ای تبدیل می‌شود نه یک پاسخ.

با فازها شروع کنید، نه playbook

NIST SP 800-61 چهار فاز را تعریف می‌کند: آمادگی،탐지و تحلیل، محدودسازی/ریشه‌کنی/بازیابی، و فعالیت پس از حادثه. ترتیب اهمیت دارد. تیم‌ها دوست دارند مستقیماً به محدودسازی بروند زیرا احساس بهره‌وری می‌دهد، اما اگر کار آمادگی را انجام نداده‌اید، شبکه خود را به خوبی نمی‌شناسید که چیزی را به‌طور تمیز محدود کنید.

آمادگی به معنی فهرست‌های دارایی است که واقعاً به‌روز هستند، نه صفحه گسترده‌ای از 2022. یعنی دانستن پنجره حفظ لاگ شما (اگر 7 روز است و مهاجم 30 روز زمان ماندگاری داشته، شما از دست دادید timeline را). یعنی ابزارهای تحقیق پیش‌مرحله‌ای — Velociraptor، KAPE، یا حتی یک tar/dd procedure مستند‌شده برای disk image — به‌طوری که هیچ‌کس در حین یک حادثه فعال ابزار را روی یک میزبان compromised دانلود نمی‌کند.

سطح‌های شدت را پیش از اینکه نیاز داشته باشید تعریف کنید

یک SEV1 (exfiltration داده فعال، detonation ransomware، domain admin compromise) نیاز به پاسخ متفاوتی دارد از یک SEV3 (isolated malware روی یک workstation بدون امتیاز). این را به‌صورت یک ماتریس بنویسید: تأثیر در مقابل scope در مقابل confidence. به هر شدت یک زمان پاسخ مورد نیاز و یک مسیر escalation اختصاص دهید. اگر incident commander شما برای یک SEV1 همان شخصی است که باید هر order خریدی 500 دلاری را تصویب کند، شما یک bottleneck در فرایند اضطراری خود ایجاد کرده‌اید.

نقش incident commander اختیاری نیست

یک نفر حادثه را مدیریت می‌کند. نه بر اساس پیش‌فرض مهندس ارشد‌ترین — شخصی که برای هماهنگی، تفویض و تصمیم‌گیری محدودسازی تحت فشار بهترین است. این شخص لازماً در حین پاسخ صفحه‌کلید را لمس نمی‌کند؛ آن‌ها timeline را ردیابی می‌کنند، ارتباط با حقوقی و رهبری را مدیریت می‌کنند، و تصمیم می‌گیرند که چه موقع بر عزم خود برای isolating segment یا offline کردن سیستم عمل کنند.

بدون این نقش، پنج نفر SSH شده به یک box هستند، هیچ‌کدام از آن‌ها با یکدیگر صحبت نمی‌کنند، و هیچ‌کس volatile memory را capture نمی‌کند پیش از اینکه کسی ماشین را reboot کند تا "ببیند آیا ببخشند."

تصمیم‌های محدودسازی که واقعاً اهمیت دارند

سخت‌ترین تصمیم در اکثر حادثه‌ها این است: الان isolate شود یا کمی بیشتر observe کنیم تا scope را بفهمیم؟ network access را خیلی زود قطع کردن مهاجم را هشدار می‌دهد که هنوز lateral movement می‌کند و شانس شما را برای دیدن حرکت بعدی آن‌ها نابود می‌کند. منتظر شدن خیلی طولانی ransomware را اجازه می‌دهد که share ها را رمزگذاری کند.

یک راه میانه معقول: network segmentation و EDR isolation (CrowdStrike، Defender for Endpoint، SentinelOne همه این را پشتیبانی می‌کنند) را استفاده کنید تا host را از lateral movement قطع کنید در حالی که آن را روشن نگه دارید برای memory capture. Full shutdown باید آخرین راه باشد — volatile evidence را کشته می‌کند و برای ransomware cases، می‌تواند anti-forensic behavior که در برخی payloads embedded است را trigger کند.

Logging gaps که طی آن پشیمان خواهید شد، نه پیش از آن

Windows Event Log defaults کافی نیست. اگر Sysmon deployed نداشته باشید با یک config مناسب (baseline configs SwiftOnSecurity یا Olaf Hartong یک نقطه شروع جامد هستند)، process trees را از fragments بازسازی می‌کنید. روی سمت network، NetFlow یا Zeek logs بیشتر از آنچه اکثر orgs تا زمانی که نیاز دارند درک می‌کنند اهمیت دارند