پاسخ به حادثه چیست؟#

پاسخ به حادثه (Incident Response یا IR) فرایندی ساختاریافته است که سازمان برای کشف، مهار، رفع و بازیابی از نقض‌های امنیتی به کار می‌گیرد. هدف IR نه «جلوگیری از همهٔ حوادث» (که غیرممکن است) بلکه کاهش زمان تشخیص (MTTD) و زمان رفع (MTTR) و در نتیجه کاهش خسارت است.

طبق گزارش IBM Cost of a Data Breach ۲۰۲۵، سازمان‌هایی که تیم IR و برنامهٔ رسمی دارند، میانگین هزینهٔ هر نقض را ۲٫۶۶ میلیون دلار کمتر پرداخت می‌کنند. در مقابل، سازمان‌هایی که بدون برنامهٔ IR هستند، زمان شناسایی و مهار حادثه به‌طور میانگین ۲۷۷ روز طول می‌کشد؛ یعنی مهاجم نزدیک به ۹ ماه در شبکه دسترسی داشته است.

چرخهٔ NIST IR#

مؤسسهٔ استانداردها و فناوری آمریکا (NIST) در SP 800-61 چرخهٔ چهار مرحله‌ای IR را تعریف می‌کند:

  ┌───────────────────────┐
  │ 1. Preparation        │  ← سیاست، تیم، ابزار، آموزش
  └──────────┬────────────┘
             ▼
  ┌───────────────────────┐
  │ 2. Detection &        │  ← کشف با SIEM، IDS، گزارش کاربر
  │    Analysis           │
  └──────────┬────────────┘
             ▼
  ┌───────────────────────┐
  │ 3. Containment,       │  ← ایزوله‌کردن، قطع شبکه، ریشه‌یابی
  │    Eradication &      │
  │    Recovery           │
  └──────────┬────────────┘
             ▼
  ┌───────────────────────┐
  │ 4. Post-Incident      │  ← گزارش، درس‌آموخته‌ها، بهبود
  │    Activity           │
  └───────────────────────┘

چرخهٔ SANS#

SANS Institute چرخهٔ شش مرحله‌ای مشابهی ارائه می‌دهد که در عمل معادل NIST است اما مراحل را ریزتر می‌کند:

ایجاد برنامهٔ IR#

یک برنامهٔ IR مؤثر باید این بخش‌ها را داشته باشد:

۱. تعریف حادثه: انواع حوادث (مال‌افزاری، فیشینگ، DDoS، نفوذ، از دست رفتن داده) با سطوح شدت (Severity 1 تا 4).

۲. تیم CSIRT (Computer Security Incident Response Team): نقش‌ها و مسئولیت‌ها:

• IR Lead: رهبری عملیات، تصمیم‌گیری فنی
• SOC Analyst: مانیتورینگ، تحلیل اولیه
• Forensics: جمع‌آوری و تحلیل شواهد
• Communications: هماهنگی با مدیریت، حقوقی، روابط عمومی
• Legal/Compliance: الزامات قانونی (مانند GDPR ۷۲ ساعت)
• Executive Sponsor: اختیار تأیید اقدامات بزرگ

۳. ماتریس تشدید (Escalation): چه کسی در چه شدتی درگیر می‌شود و در چه زمانی به مدیریت گزارش داده می‌شود.

۴. Runbooks: راهنمای گام‌به‌گام برای سناریوهای شناخته‌شده (مثلاً «Runbook-Phishing»، «Runbook-Ransomware»، «Runbook-DDoS»).

۵. تمرین (Tabletop Exercise): شبیه‌سازی سالانه برای آزمایش برنامه بدون فشار واقعی.

ابزارهای تشخیص#

SIEM (Security Information and Event Management): تمام لاگ‌های سازمان (فایروال، Endpoint، IAM، اپلیکیشن) را جمع‌آوری و با همبسته‌سازی (Correlation) الگوهای مشکوک را شناسایی می‌کند. نمونه‌ها: Splunk، Microsoft Sentinel، Elastic SIEM، Wazuh.

IDS/IPS: Snort و Suricata هشدار یا مسدودسازی بر اساس امضای ترافیک مخرب.

EDR: رفتار Endpoint را ثبت و تحلیل می‌کند؛ در شناسایی حرکت جانبی و اجرای مشکوک بسیار مؤثر است.

Threat Intelligence: فیدهایی مانند MISP و VirusTotal که IOCهای شناخته‌شده (IP، دامنه، هش فایل) را در اختیار می‌گذارند.

مبانی پزشکی قانونی دیجیتال#

وقتی حادثه‌ای رخ داد، هدف نه فقط «درست کردن» بلکه «فهمیدن چه شده و چه کسی مسئول است» است. این مرحله نیاز به رعایت اصول پزشکی قانونی دارد:

۱. حفظ شواهد (Preservation): هرگز روی سیستم آلوده تحقیق نکنید؛ آن را خاموش نکنید (RAM اطلاعات ارزشمندی دارد) اما از شبکه قطع کنید. یک تصویر باینری (DD یا FTK Imager) بگیرید.

۲. زنجیرهٔ Custody (Chain of Custody): سندی از انتقال شواهد از زمان جمع‌آوری تا ارائه در دادگاه؛ شامل چه کسی، چه زمانی، چه چیزی را دریافت و به چه کسی تحویل داد. شکستن زنجیره، شواهد را در دادگاه بی‌اعتبار می‌کند.

۳. ترتیب فرّاریت (Order of Volatility): از دادهٔ فرّار به ساکن جمع‌آوری کنید: CPU/Cache → RAM → Swap → Disk → Removable Media.

۴. هش گرفتن: با sha256sum هش تصویر پزشکی قانونی را ثبت و امضا کنید تا اصالت قابل تأیید باشد.

# تصویر پزشکی قانونی از RAM با LiME (لینوکس)
insmod lime.ko "path=/tmp/ram.lime format=lime"
 
# تصویر دیسک با dd و محاسبهٔ هش
dd if=/dev/sda of=/mnt/evidence/disk.img bs=4M conv=sync,noerror
sha256sum /mnt/evidence/disk.img > /mnt/evidence/disk.img.sha256

تمرین عملی: مانیتورینگ لاگ در لینوکس#

برای کشف زودهنگام حادثه، مانیتورینگ لاگ فعال ضروری است:

# مشاهدهٔ زندهٔ لاگ‌های SSH
sudo journalctl -f -u sshd
 
# ۲۰ تلاش ناموفق ورود اخیر
sudo grep "Failed password" /var/log/auth.log | tail -20
 
# شمارش تلاش‌های ناموفق به تفکیک IP
sudo grep "Failed password" /var/log/auth.log \
  | awk '{print $(NF-3)}' \
  | sort \
  | uniq -c \
  | sort -nr \
  | head -20
 
# جستجوی ورود موفق از IP ناشناس
sudo grep "Accepted password" /var/log/auth.log \
  | awk '{print $11}' \
  | sort -u
 
# لاگ‌های sudo برای شناسایی سوءاستفاده از دسترسی
sudo journalctl -u sudo -S today

نمونهٔ خروجی هشدارناک:

   1432 185.220.101.45    ← بیش از هزار تلاش در یک ساعت: حملهٔ Brute Force
    847 45.146.165.37
    312 193.27.228.142

اگر چنین الگویی دیدید، باید فوراً IP را با فایروال مسدود کنید، SSH را به کلید عمومی محدود کنید و fail2ban را فعال کنید.

جدول مراحل IR با اقدامات کلیدی#

خلاصه و گام بعدی#

در این فصل آموختید که پاسخ به حادثه یک فرایند ساختاریافته است که با چرخهٔ NIST (چهار مرحله‌ای) و SANS (شش مرحله‌ای) اجرا می‌شود. با نقش‌های تیم CSIRT، ابزارهای تشخیص (SIEM، IDS، EDR) و اصول پزشکی قانونی دیجیتال (حفظ شواهد، زنجیرهٔ Custody، ترتیب فرّاریت) آشنا شدید و یک مانیتورینگ عملی لاگ SSH را در لینوکس پیاده کردید.

در فصل بعد، با امنیت لینوکس به‌عنوان بنیان امنیتی سرورها آشنا می‌شویم؛ از مدیریت دسترسی و SSH تا SELinux و ممیزی با Lynis.