مدیریت ریسک و حوادث امنیت سایبری؛ از ارزیابی تهدید تا پاسخ و بازیابی

حملات سایبری دیگر فقط یک مسئله فنی برای واحد فناوری اطلاعات نیستند. امروزه امنیت سایبری به یکی از ارکان اصلی مدیریت ریسک سازمان‌ها تبدیل شده است؛ زیرا یک نفوذ موفق می‌تواند موجب توقف سرویس‌های حیاتی، افشای اطلاعات، از دست رفتن داده‌ها، خسارت مالی، آسیب به اعتبار سازمان و ایجاد پیامدهای حقوقی و قراردادی شود. به همین دلیل، سازمان‌ها باید پیش از وقوع حادثه بدانند چه دارایی‌هایی دارند، چه تهدیدهایی آنها را هدف قرار می‌دهند و در صورت وقوع حمله چه اقداماتی باید انجام دهند.
مدیریت ریسک امنیت سایبری دقیقاً با همین هدف انجام می‌شود. این فرایند به سازمان کمک می‌کند دارایی‌ها، تهدیدها و آسیب‌پذیری‌های خود را شناسایی کند، احتمال و پیامد سناریوهای مختلف را بسنجد و کنترل‌های امنیتی را بر اساس میزان اهمیت ریسک‌ها در اولویت قرار دهد.
در سوی دیگر، مدیریت حادثه امنیتی مشخص می‌کند اگر حمله‌ای واقعاً رخ داد، چه کسی مسئول تصمیم‌گیری است، چگونه باید حادثه شناسایی و مهار شود، چه شواهدی باید حفظ شوند و سیستم‌های آسیب‌دیده چگونه به شرایط عادی بازگردند.
چارچوب NIST CSF 2.0 نیز چنین رویکرد یکپارچه‌ای دارد و فعالیت‌های امنیت سایبری را در شش عملکرد اصلی Govern، Identify، Protect، Detect، Respond و Recover سازمان‌دهی می‌کند. بنابراین مدیریت مؤثر امنیت سایبری فقط پیشگیری از حمله نیست؛ بلکه از حاکمیت و شناخت ریسک آغاز می‌شود و تا پاسخ و بازیابی پس از حادثه ادامه پیدا می‌کند.

مدیریت ریسک امنیت سایبری چیست؟

مدیریت ریسک امنیت سایبری یا Cybersecurity Risk Management فرایندی مستمر برای شناسایی، ارزیابی، اولویت‌بندی و کنترل ریسک‌هایی است که می‌توانند محرمانگی، یکپارچگی یا دسترس‌پذیری اطلاعات و سامانه‌های سازمان را تحت تأثیر قرار دهند.
در این فرایند سازمان تلاش می‌کند به چند سؤال مهم پاسخ دهد:
•    چه دارایی‌ها و اطلاعاتی برای سازمان اهمیت بیشتری دارند؟
•    چه تهدیدهایی این دارایی‌ها را هدف قرار می‌دهند؟
•    چه آسیب‌پذیری‌هایی در زیرساخت یا فرایندها وجود دارد؟
•    احتمال وقوع هر سناریوی تهدید چقدر است؟
•    در صورت وقوع حادثه چه میزان خسارت ایجاد می‌شود؟
•    برای کاهش ریسک چه کنترل‌هایی باید اجرا شوند؟
هدف مدیریت ریسک، حذف کامل تمام تهدیدات نیست. چنین کاری در عمل تقریباً غیرممکن است. هدف اصلی این است که سازمان ریسک‌های خود را بشناسد و آنها را تا سطح قابل‌قبول کاهش دهد.

تفاوت تهدید، آسیب‌پذیری و ریسک چیست؟

سه مفهوم Threat، Vulnerability و Risk ارتباط نزدیکی با یکدیگر دارند اما یکسان نیستند.
تهدید یا Threat عاملی است که توانایی ایجاد خسارت دارد؛ مانند مهاجم سایبری، باج‌افزار، کارمند مخرب یا گروه مجرمان سایبری.
آسیب‌پذیری یا Vulnerability ضعفی است که تهدید می‌تواند از آن سوءاستفاده کند؛ مانند نرم‌افزار به‌روزرسانی‌نشده، تنظیمات اشتباه، رمز عبور ضعیف یا دسترسی بیش از حد کاربران.
ریسک یا Risk احتمال بهره‌برداری یک تهدید از آسیب‌پذیری و شدت پیامد احتمالی آن است.
برای مثال:
•    دارایی: سرور نگهداری اطلاعات مشتریان
•    آسیب‌پذیری: سیستم‌عامل Patch نشده
•    تهدید: مهاجم یا باج‌افزار
•    پیامد: افشای اطلاعات یا توقف سرویس
ترکیب این عوامل یک سناریوی ریسک امنیت سایبری را شکل می‌دهد.

مدیریت حادثه امنیت سایبری چیست؟

مدیریت حادثه امنیتی یا Cybersecurity Incident Management مجموعه اقداماتی است که برای شناسایی، تحلیل، مهار، حذف و بازیابی یک حادثه امنیتی انجام می‌شود.
اگر مدیریت ریسک تلاش می‌کند پیش از وقوع یک تهدید خسارت آن را کاهش دهد، Incident Management بیشتر بر شرایطی تمرکز دارد که تهدید بالفعل شده یا نشانه‌های جدی از وقوع آن مشاهده شده است.
هدف اصلی مدیریت Incident عبارت است از:
•    تشخیص سریع حادثه؛
•    محدود کردن دامنه نفوذ؛
•    جلوگیری از گسترش خسارت؛
•    حفظ شواهد مورد نیاز؛
•    حذف عامل اصلی حمله؛
•    بازیابی ایمن سرویس‌ها؛
•    جلوگیری از تکرار حادثه.

رویداد امنیتی چه زمانی به حادثه امنیتی تبدیل می‌شود؟

هر Security Event الزاماً یک Security Incident نیست.
برای مثال، چند تلاش ناموفق برای ورود به حساب کاربری ممکن است فقط یک رویداد امنیتی باشد. اما اگر مهاجم موفق به ورود شود و به اطلاعات غیرمجاز دسترسی پیدا کند، یک Incident واقعی رخ داده است.
به همین شکل:
•    افزایش غیرعادی ترافیک → ممکن است یک Event باشد.
•    توقف سرویس در نتیجه حمله DDoS → Incident است.
•    مشاهده فایل ناشناخته روی Endpoint → می‌تواند Event باشد.
•    اجرای Malware و دسترسی مهاجم به شبکه → Incident است.
تفکیک صحیح Event و Incident باعث می‌شود تیم امنیت منابع خود را روی تهدیدهای واقعی متمرکز کند.

چرا مدیریت ریسک و پاسخ به حادثه باید یک چرخه واحد باشند؟

مدیریت ریسک و پاسخ به حادثه نباید دو فعالیت جدا از یکدیگر تلقی شوند.
نتایج Risk Assessment باید مستقیماً بر Incident Response Plan اثر بگذارند. اگر ارزیابی ریسک نشان دهد باج‌افزار یکی از مهم‌ترین تهدیدهای سازمان است، باید برای Ransomware یک Playbook مشخص تهیه شود و موضوعاتی مانند Backup، EDR، Network Segmentation و Recovery از قبل برنامه‌ریزی شوند.
در مقابل، Incidentهای واقعی نیز اطلاعات ارزشمندی برای ارزیابی مجدد ریسک فراهم می‌کنند.
چرخه مناسب را می‌توان این‌گونه نمایش داد:
شناسایی دارایی → شناسایی تهدید → ارزیابی ریسک → اجرای کنترل → پایش → تشخیص حادثه → پاسخ → بازیابی → درس‌آموخته‌ها → ارزیابی مجدد ریسک
این چرخه یکی از پایه‌های Cyber Resilience یا تاب‌آوری سایبری است.

نقش NIST CSF 2.0 در مدیریت ریسک و حوادث سایبری

NIST Cybersecurity Framework یکی از چارچوب‌های شناخته‌شده برای سامان‌دهی مدیریت ریسک امنیت سایبری است.
NIST CSF 2.0 فعالیت‌های امنیتی را در شش Function اصلی سازمان‌دهی می‌کند:
Govern – Identify – Protect – Detect – Respond – Recover
این ساختار نشان می‌دهد امنیت تنها مجموعه‌ای از ابزارهای فنی نیست؛ بلکه از تصمیم‌گیری مدیریتی شروع می‌شود و تا بازیابی فعالیت‌های سازمان پس از حادثه ادامه دارد.

Govern؛ راهبری و حاکمیت امنیت سایبری

Govern به نحوه هدایت، سیاست‌گذاری و مدیریت ریسک سایبری در سطح سازمان مربوط است.
در این مرحله باید موضوعاتی مانند موارد زیر مشخص شوند:
•    مسئولیت مدیران؛
•    سیاست‌های امنیت اطلاعات؛
•    نقش‌ها و اختیارات؛
•    Risk Appetite؛
•    مدیریت ریسک زنجیره تأمین؛
•    نظارت بر عملکرد امنیت؛
•    مسئولیت مالک هر ریسک.
یکی از اشتباهات رایج آن است که امنیت سایبری صرفاً مسئولیت IT یا تیم امنیت تلقی شود. در حالی که پذیرش یک ریسک بزرگ یا تخصیص بودجه برای کاهش آن ممکن است به تصمیم مدیریت ارشد نیاز داشته باشد.

Identify؛ شناسایی دارایی‌ها و ریسک‌ها

در مرحله Identify سازمان باید بداند چه چیزهایی دارد و چه چیزهایی را باید محافظت کند.
موضوعات مهم عبارت‌اند از:
•    Asset Inventory؛
•    Data Classification؛
•    شناسایی سرویس‌های حیاتی؛
•    شناخت وابستگی میان سیستم‌ها؛
•    Threat Identification؛
•    Risk Assessment.
بدون شناخت صحیح دارایی‌ها، حتی بهترین ابزارهای امنیتی نیز ممکن است در جای اشتباه استفاده شوند.
Protect؛ کاهش احتمال و پیامد حمله
Protect شامل کنترل‌هایی است که احتمال وقوع حادثه یا شدت خسارت آن را کاهش می‌دهند.
از جمله:
•    MFA؛
•    Access Control؛
•    Patch Management؛
•    Backup؛
•    Data Protection؛
•    Security Awareness؛
•    Hardening؛
•    مدیریت حساب‌های کاربری.
در سازمان‌هایی با تعداد زیاد کاربران و سرویس‌ها، استفاده از سامانه احرازهویت یکپارچه کاربران می‌تواند به متمرکز شدن مدیریت هویت و دسترسی کمک کند. این کار کنترل ایجاد، تغییر و حذف حساب‌ها را ساده‌تر می‌کند و احتمال باقی ماندن حساب‌های قدیمی یا دسترسی‌های غیرضروری را کاهش می‌دهد.
در کنار آن، استفاده از سامانه مدیریت رمز می‌تواند مدیریت Credentialهای حساس را ساختاریافته‌تر کند. رمزهای مدیریتی، دسترسی‌های زیرساختی و اطلاعات احراز هویت نباید در فایل‌های پراکنده، پیام‌رسان‌ها یا حافظه مرورگرها نگهداری شوند.
حفاظت از اطلاعات هنگام جابه‌جایی نیز اهمیت بالایی دارد. استفاده از سامانه انتقال امن فایل می‌تواند مسیر رسمی و کنترل‌شده‌ای برای انتقال اطلاعات سازمانی فراهم کند و وابستگی کارکنان به سرویس‌های عمومی یا کانال‌های غیرقابل‌کنترل را کاهش دهد.
همچنین در محیط‌هایی که اطلاعات سازمانی از طریق پورتال‌های داخلی یا خارجی در اختیار کاربران قرار می‌گیرند، سامانه انتشار امن پورتال سازمانی می‌تواند بخشی از معماری کنترل انتشار، مدیریت دسترسی و ثبت رویدادهای مرتبط با انتشار اطلاعات باشد.

Detect؛ شناسایی رفتار مشکوک

هیچ کنترل پیشگیرانه‌ای نمی‌تواند احتمال موفقیت حمله را به صفر برساند. بنابراین سازمان باید توانایی کشف فعالیت‌های غیرعادی را داشته باشد.
ابزارهای رایج در این مرحله عبارت‌اند از:
•    SIEM؛
•    EDR؛
•    XDR؛
•    IDS/IPS؛
•    Log Management؛
•    Network Monitoring؛
•    SOC.
هرچه فاصله زمانی بین آغاز نفوذ و شناسایی آن کمتر شود، احتمال محدود کردن خسارت بیشتر خواهد بود.
Respond؛ مهار و پاسخ
Respond زمانی آغاز می‌شود که Incident شناسایی شده است.
فعالیت‌های این مرحله شامل:
•    تحلیل حادثه؛
•    Incident Classification؛
•    Containment؛
•    Communication؛
•    Eradication؛
•    هماهنگی تیم‌ها؛
•    مستندسازی اقدامات.
Recover؛ بازیابی سرویس و عملیات
پس از مهار و حذف عامل تهدید، باید سرویس‌ها به شکل کنترل‌شده بازیابی شوند.
در این مرحله موضوعاتی مانند:
•    Backup Recovery؛
•    Disaster Recovery؛
•    Business Continuity؛
•    RTO؛
•    RPO؛
•    Post-Incident Review
اهمیت پیدا می‌کنند.

ارزیابی ریسک امنیت سایبری چگونه انجام می‌شود؟

ارزیابی ریسک امنیت یکی از اصلی‌ترین مراحل مدیریت ریسک سایبری است. بدون Risk Assessment، مشخص نیست کدام تهدید اهمیت بیشتری دارد و منابع امنیتی باید در کجا هزینه شوند.

مرحله اول: شناسایی دارایی‌های حیاتی

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

مرحله دوم: شناسایی تهدیدها

تهدیدهای متداول عبارت‌اند از:
•    Ransomware؛
•    Phishing؛
•    Malware؛
•    Credential Theft؛
•    DDoS؛
•    Insider Threat؛
•    Supply Chain Attack؛
•    Exploitation of Vulnerabilities؛
•    حملات Zero-day.
همه سازمان‌ها با سطح یکسانی از این تهدیدها مواجه نیستند؛ بنابراین اولویت‌بندی باید بر اساس محیط واقعی سازمان انجام شود.

مرحله سوم: شناسایی آسیب‌پذیری‌ها

نمونه‌هایی از Vulnerability یا ضعف‌های امنیتی عبارت‌اند از:
•    نرم‌افزارهای Patch نشده؛
•    تنظیمات نادرست؛
•    Password ضعیف؛
•    سرویس‌های غیرضروری؛
•    نبود MFA؛
•    مجوزهای بیش از حد؛
•    ضعف در Network Segmentation؛
•    نبود Logging کافی؛
•    Backup ناکافی.
Vulnerability Assessment، Configuration Review و در موارد مناسب Penetration Testing می‌توانند در شناسایی این ضعف‌ها کمک کنند.

مرحله چهارم: بررسی احتمال و پیامد

در مدل‌های ساده می‌توان ریسک را به‌صورت مفهومی این‌گونه بیان کرد:
Risk = Likelihood × Impact
Likelihood میزان احتمال وقوع یک سناریو را نشان می‌دهد.
Impact میزان خسارت احتمالی را مشخص می‌کند.
پیامد یک Incident ممکن است:
•    مالی؛
•    عملیاتی؛
•    حقوقی؛
•    اعتباری؛
•    قراردادی؛
•    مرتبط با امنیت اطلاعات
باشد.

مرحله پنجم: اولویت‌بندی ریسک

پس از ارزیابی، ریسک‌ها می‌توانند بر اساس Risk Matrix طبقه‌بندی شوند:
•    کم؛
•    متوسط؛
•    زیاد؛
•    بحرانی.
Risk Score به سازمان کمک می‌کند تصمیم بگیرد کدام موضوع باید زودتر اصلاح شود.

با ریسک‌های شناسایی‌شده چه باید کرد؟

پس از شناسایی ریسک، چهار استراتژی اصلی وجود دارد.

کاهش ریسک یا Risk Mitigation

در این رویکرد کنترل‌هایی اجرا می‌شوند تا احتمال یا پیامد ریسک کاهش یابد.
برای مثال اگر انتقال غیرقابل‌کنترل فایل یکی از مسیرهای نشت اطلاعات باشد، استفاده از سامانه انتقال امن فایل همراه با Access Control، Logging و سیاست‌های تعیین‌شده برای اشتراک‌گذاری اطلاعات می‌تواند بخشی از Risk Mitigation باشد.
اگر مشکل سازمان پراکندگی حساب‌های کاربری و سطوح دسترسی باشد، سامانه احرازهویت یکپارچه کاربران می‌تواند بخشی از راهکار مدیریت متمرکز هویت باشد.
در محیط‌هایی که Credentialهای حساس متعدد وجود دارند نیز سامانه مدیریت رمز می‌تواند احتمال نگهداری ناامن رمزها یا اشتراک آنها میان افراد را کاهش دهد.

اجتناب از ریسک یا Risk Avoidance

گاهی یک فعالیت آن‌قدر پرریسک است که سازمان تصمیم می‌گیرد آن را متوقف کند.
برای مثال ممکن است سرویس قدیمی، آسیب‌پذیر و غیرضروری به‌طور کامل از شبکه حذف شود.

انتقال ریسک یا Risk Transfer

سازمان می‌تواند بخشی از اثر مالی یا قراردادی ریسک را از طریق قراردادها، تأمین‌کنندگان یا بیمه سایبری منتقل کند.
البته Risk Transfer به معنی حذف مسئولیت امنیتی سازمان نیست.

پذیرش ریسک یا Risk Acceptance

برخی ریسک‌ها ممکن است با توجه به هزینه کنترل و Impact احتمالی پذیرفته شوند.
پذیرش باید آگاهانه، مستند و در محدوده Risk Appetite سازمان باشد.

برنامه پاسخ به حادثه امنیت سایبری چیست؟

Incident Response Plan سند و فرایندی است که نحوه واکنش سازمان به یک Incident را از قبل مشخص می‌کند.
در این برنامه باید پاسخ سؤالات زیر روشن باشد:
•    چه کسی Incident را اعلام می‌کند؟
•    چه کسی Severity را تعیین می‌کند؟
•    چه کسی مسئول Incident Commander است؟
•    چه زمانی باید مدیران مطلع شوند؟
•    چه کسی اجازه ایزوله‌کردن یک سیستم حیاتی را دارد؟
•    چه Logها و شواهدی باید حفظ شوند؟
•    چه تیم‌هایی باید درگیر شوند؟
•    ارتباط با مشتری یا ذی‌نفعان چگونه مدیریت شود؟
•    چه شرایطی برای آغاز Recovery وجود دارد؟
داشتن این برنامه باعث می‌شود در شرایط بحران، تصمیم‌گیری به واکنش‌های لحظه‌ای وابسته نباشد.

مراحل پاسخ به حملات سایبری

اگرچه نوع حمله بر جزئیات Incident Response اثر می‌گذارد، فرایند کلی معمولاً شامل چند مرحله مشخص است.

1. آمادگی قبل از حادثه

آمادگی یکی از مهم‌ترین بخش‌های Incident Response است.
اقدامات مهم عبارت‌اند از:
•    تشکیل Incident Response Team؛
•    تعیین مسئولیت‌ها؛
•    تهیه Incident Response Plan؛
•    تهیه Playbook؛
•    فعال‌سازی Logging؛
•    ایجاد Monitoring؛
•    تهیه و آزمایش Backup؛
•    تعریف کانال ارتباط اضطراری؛
•    آموزش کارکنان؛
•    اجرای Tabletop Exercise.
کنترل‌های پیشگیرانه نیز باید پیش از وقوع حادثه آماده باشند. برای مثال مدیریت متمرکز هویت، مدیریت امن Credentialها، تعریف مسیر رسمی انتقال فایل و کنترل نحوه انتشار اطلاعات سازمانی می‌توانند Attack Surface را کاهش دهند.
در برخی شبکه‌های حساس، معماری‌هایی مانند جداسازی اینترنت از اینترنت نیز با هدف کاهش ارتباط مستقیم بخش‌های حساس با شبکه‌های عمومی مطرح می‌شوند. البته نحوه تفکیک شبکه باید با نیاز عملیاتی، Risk Assessment و سطح حساسیت اطلاعات هماهنگ باشد و جایگزین سایر کنترل‌ها نیست.

2. شناسایی و تحلیل Incident

پس از دریافت Alert باید مشخص شود:
•    آیا واقعاً Incident رخ داده است؟
•    نقطه شروع حادثه کجاست؟
•    چه سیستم‌هایی تحت تأثیر قرار گرفته‌اند؟
•    مهاجم چه اقداماتی انجام داده است؟
•    آیا اطلاعات خارج شده‌اند؟
•    آیا حرکت جانبی در شبکه رخ داده است؟
منابع بررسی می‌توانند شامل:
•    SIEM؛
•    EDR؛
•    Firewall Logs؛
•    Authentication Logs؛
•    DNS Logs؛
•    IDS/IPS؛
•    Threat Intelligence
باشند.
Indicators of Compromise یا IOCها نیز در این مرحله اهمیت دارند.

3. مهار حادثه

هدف Containment جلوگیری از گسترش Incident است.
اقدامات ممکن عبارت‌اند از:
•    Isolation سیستم آلوده؛
•    غیرفعال کردن Account؛
•    Block کردن IP یا Domain؛
•    قطع Session؛
•    جداسازی Segment شبکه؛
•    محدود کردن ارتباط سیستم؛
•    تغییر Credentialهای در معرض خطر.
مهار باید کنترل‌شده باشد. خاموش کردن سریع یک سیستم ممکن است در برخی شرایط باعث از دست رفتن اطلاعات ارزشمند Forensics شود.

4. حذف عامل تهدید

پس از مهار باید Root Cause شناسایی و رفع شود.
برای مثال:
•    Malware حذف شود؛
•    Vulnerability Patch شود؛
•    Persistence مهاجم حذف شود؛
•    Passwordها تغییر کنند؛
•    Tokenهای مشکوک لغو شوند؛
•    Configuration اشتباه اصلاح شود.
اگر فقط سرویس بازیابی شود و علت اصلی نفوذ باقی بماند، احتمال بازگشت مهاجم وجود دارد.

5. بازیابی سیستم‌ها

سیستم‌ها باید مرحله‌ای و کنترل‌شده به محیط عملیاتی برگردند.
پیش از Recovery بررسی کنید:
•    Root Cause رفع شده است؟
•    Malware حذف شده است؟
•    Credentialها تعویض شده‌اند؟
•    Patch نصب شده است؟
•    Backup سالم است؟
•    Monitoring فعال است؟

6. بررسی پس از حادثه

Post-Incident Review مرحله‌ای ضروری است.
باید پاسخ داده شود:
•    حمله چگونه آغاز شد؟
•    چرا پیشگیری نشد؟
•    چرا در زمان مشخصی Detect شد؟
•    چه کنترل‌هایی درست عمل کردند؟
•    چه مشکلاتی در Incident Response وجود داشت؟
•    چه چیزی باید اصلاح شود؟
Lessons Learned باید باعث اصلاح Risk Register، Policyها، Playbookها و کنترل‌های فنی شود.

در ساعات اولیه حمله سایبری چه اقداماتی انجام دهیم؟

اولین ساعات یک Incident می‌تواند تأثیر تعیین‌کننده‌ای بر میزان خسارت داشته باشد.
ترتیب کلی اقدامات می‌تواند شامل موارد زیر باشد:
1.    Alert را اعتبارسنجی و Incident را ثبت کنید.
2.    Severity را مشخص کنید.
3.    Incident Response Team را فعال کنید.
4.    دامنه اولیه حادثه را تعیین کنید.
5.    سیستم‌های آلوده را در صورت نیاز ایزوله کنید.
6.    از گسترش Incident جلوگیری کنید.
7.    Logها و شواهد را حفظ کنید.
8.    حساب‌ها و Credentialهای مشکوک را بررسی کنید.
9.    دامنه نفوذ و Lateral Movement را مشخص کنید.
10.    Root Cause را بررسی کنید.
11.    ذی‌نفعان لازم را مطلع کنید.
12.    پس از مهار و Eradication وارد Recovery شوید.
مهم است اقدامات فوری موجب تخریب شواهد Digital Forensics نشوند.

چگونه شدت یک حادثه سایبری را تعیین کنیم؟

تمام Incidentها اهمیت یکسانی ندارند. Incident Classification کمک می‌کند منابع و Escalation متناسب با شدت حادثه انتخاب شوند.
سطح 1: کم
اثر محدود دارد و سرویس حیاتی مختل نشده است.
سطح 2: متوسط
بخشی از سیستم‌ها یا کاربران تحت تأثیر هستند، اما فعالیت اصلی سازمان ادامه دارد.
سطح 3: شدید
سرویس مهم دچار اختلال شده یا احتمال افشای اطلاعات حساس وجود دارد.
سطح 4: بحرانی
حادثه بخش وسیعی از شبکه، اطلاعات حساس یا سرویس‌های حیاتی را درگیر کرده و ممکن است فعالیت اصلی سازمان را متوقف کند.
برای تعیین Severity می‌توان موارد زیر را بررسی کرد:
•    تعداد سیستم‌های درگیر؛
•    نوع داده‌های تحت تأثیر؛
•    Criticality سرویس؛
•    مدت Downtime؛
•    دامنه دسترسی مهاجم؛
•    احتمال گسترش Incident.

تیم پاسخ به حادثه امنیتی شامل چه افرادی است؟

Incident Response صرفاً وظیفه یک تیم فنی نیست.
بسته به نوع Incident ممکن است افراد زیر درگیر شوند:
•    CISO؛
•    SOC؛
•    Incident Response Team؛
•    تیم Network؛
•    مدیران System؛
•    Digital Forensics؛
•    مدیریت ارشد؛
•    واحد حقوقی؛
•    روابط عمومی؛
•    منابع انسانی؛
•    مسئول Business Continuity.
در یک Data Breach بزرگ، تیم فنی می‌تواند مهاجم را مهار کند اما تصمیم درباره اطلاع‌رسانی، اثر حقوقی یا ادامه سرویس ممکن است به واحدهای دیگری وابسته باشد.

پاسخ به انواع حملات سایبری چه تفاوتی دارد؟

چارچوب کلی Incident Response یکسان است، اما Playbook هر حمله باید متناسب با روش و پیامد آن طراحی شود.

پاسخ به حمله باج‌افزاری

در Ransomware اولین اولویت جلوگیری از گسترش Encryption است.
باید بررسی شود:
•    چه Endpointهایی آلوده شده‌اند؟
•    آیا File Serverها درگیرند؟
•    نقطه ورود چیست؟
•    آیا مهاجم Data Exfiltration انجام داده است؟
•    آیا Backup سالم است؟
•    آیا Persistence وجود دارد؟
Offline Backup و Immutable Backup می‌توانند نقش مهمی در Recovery داشته باشند.
پاسخ به فیشینگ و سرقت حساب کاربری
در Phishing و Credential Theft اقدامات معمول شامل:
•    Password Reset؛
•    لغو Session؛
•    Revoke Token؛
•    بررسی Authentication Logs؛
•    فعال‌سازی یا بررسی MFA؛
•    جست‌وجوی فعالیت مشکوک؛
•    بررسی سایر حساب‌های در معرض خطر.
وجود سامانه احرازهویت یکپارچه کاربران می‌تواند مدیریت سریع‌تر Accountها و غیرفعال‌سازی دسترسی‌های آسیب‌دیده را تسهیل کند.
همچنین استفاده از سامانه مدیریت رمز برای Credentialهای حساس می‌تواند احتمال نگهداری ناامن یا اشتراک رمز میان کاربران را کاهش دهد.
پاسخ به نشت یا سرقت اطلاعات
در Data Breach باید مشخص شود:
•    چه اطلاعاتی درگیر شده‌اند؟
•    چه کسی به آنها دسترسی داشته است؟
•    دسترسی غیرمجاز چه مدت ادامه داشته است؟
•    آیا داده‌ها از محیط سازمان خارج شده‌اند؟
•    مسیر خروج اطلاعات چه بوده است؟
•    چه Credentialهایی درگیر بوده‌اند؟
تعریف مسیرهای رسمی تبادل فایل اهمیت زیادی دارد. سامانه انتقال امن فایل می‌تواند امکان اعمال Access Control، ثبت رویداد و کنترل بهتر تبادل فایل‌های حساس را فراهم کند.
در سازمان‌هایی که اطلاعات از طریق پورتال منتشر می‌شوند نیز سامانه انتشار امن پورتال سازمانی می‌تواند بخشی از کنترل فرایند انتشار، مجوزدهی و ثبت رویدادهای مرتبط باشد.
پاسخ به DDoS
در حملات DDoS اولویت اصلی حفظ Availability است.
روش‌های رایج عبارت‌اند از:
•    Traffic Filtering؛
•    Rate Limiting؛
•    CDN؛
•    WAF؛
•    Anti-DDoS Service؛
•    همکاری با ISP.
پاسخ به نفوذ سرور یا شبکه
در این سناریو فقط Initial Access نباید بررسی شود.
باید موضوعاتی مانند:
•    Lateral Movement؛
•    Privilege Escalation؛
•    Credential Dumping؛
•    Persistence؛
•    Command and Control
نیز بررسی شوند.

پاسخ به تهدیدات داخلی

Insider Threat پیچیده است زیرا فرد ممکن است مجوز قانونی برای دسترسی اولیه داشته باشد.
کنترل‌هایی مانند:
•    Principle of Least Privilege؛
•    Logging؛
•    UEBA؛
•    Access Review؛
•    Separation of Duties
در کاهش این ریسک اهمیت دارند.

بازیابی پس از حمله سایبری چگونه انجام می‌شود؟

Recovery صرفاً روشن کردن سرورها یا Restore کردن Backup نیست.
سیستمی که بدون رفع علت نفوذ به محیط بازگردد ممکن است دوباره مورد سوءاستفاده قرار گیرد.
ابتدا Root Cause را حذف کنید
پیش از Recovery بررسی کنید:
•    Malware حذف شده است؛
•    آسیب‌پذیری Patch شده است؛
•    Accountهای مهاجم حذف شده‌اند؛
•    Credentialها تغییر کرده‌اند؛
•    Persistence برطرف شده است؛
•    IOCهای شناخته‌شده بررسی شده‌اند.
اطلاعات را از Backup سالم بازیابی کنید
Backup باید قبل از Restore بررسی شود.
اگر Backup مربوط به زمانی باشد که مهاجم از قبل در شبکه حضور داشته، ممکن است بازگرداندن آن مشکل را مجدداً ایجاد کند.
استفاده از Offline Backup و Immutable Backup می‌تواند ریسک دستکاری نسخه‌های پشتیبان را کاهش دهد.
سرویس‌های حیاتی را اولویت‌بندی کنید
همه سیستم‌ها نباید هم‌زمان Restore شوند.
برای هر سرویس باید RTO و RPO مشخص باشد.
RTO یا Recovery Time Objective حداکثر زمان قابل‌قبول برای بازگرداندن یک سرویس است.
RPO یا Recovery Point Objective حداکثر میزان قابل‌قبول از دست رفتن داده را بر اساس زمان مشخص می‌کند.
پس از Recovery پایش را افزایش دهید
سیستم بازیابی‌شده باید برای مدتی تحت Monitoring شدیدتر قرار گیرد تا علائم Persistence یا Reinfection سریع‌تر شناسایی شوند.

تفاوت Incident Response، Disaster Recovery و Business Continuity چیست؟

این سه مفهوم مکمل یکدیگرند اما هدف یکسانی ندارند.
مفهوم    هدف اصلی
Incident Response    شناسایی، مهار و حذف حادثه امنیتی
Disaster Recovery    بازیابی زیرساخت، سیستم‌ها و اطلاعات
Business Continuity    ادامه فعالیت‌های حیاتی هنگام اختلال
برای مثال در حمله Ransomware:
Incident Response مهاجم را شناسایی و مهار می‌کند.
Disaster Recovery سرورها و اطلاعات را بازیابی می‌کند.
Business Continuity مشخص می‌کند تا زمان بازگشت کامل سیستم‌ها، فعالیت‌های ضروری سازمان چگونه ادامه پیدا کنند.

چه ابزارهایی در مدیریت ریسک و Incident Response استفاده می‌شوند؟

ابزارهای امنیتی زمانی ارزشمند هستند که بخشی از فرایند مشخص و مدیریت‌شده باشند.

SIEM

SIEM رویدادها و Logهای منابع مختلف را جمع‌آوری و تحلیل می‌کند و می‌تواند الگوهای مشکوک را به Alert تبدیل کند.

SOAR

SOAR برای Orchestration و Automation فعالیت‌های پاسخ استفاده می‌شود.
برای مثال، برخی بررسی‌های اولیه مربوط به IOCها می‌توانند خودکار شوند.

EDR و XDR

EDR رفتار Endpoint را بررسی می‌کند و برای Detect و Response روی کامپیوترها و سرورها کاربرد دارد.
XDR داده‌های چند حوزه امنیتی را برای تحلیل یکپارچه ترکیب می‌کند.

Vulnerability Scanner

برای شناسایی آسیب‌پذیری‌های شناخته‌شده و اولویت‌بندی Patchها استفاده می‌شود.

IDS و IPS

IDS رفتار مشکوک شبکه را تشخیص می‌دهد و IPS می‌تواند بخشی از ترافیک مخرب را Block کند.

Threat Intelligence

اطلاعاتی درباره Threat Actorها، IOCها، TTPها و حملات جدید فراهم می‌کند.

کنترل‌های مکمل برای کاهش ریسک سایبری

مدیریت ریسک تنها با نصب SIEM یا EDR کامل نمی‌شود. بخشی از ریسک‌ها به مدیریت هویت، تبادل داده و معماری شبکه مربوط هستند.

مدیریت هویت کاربران

کنترل مرکزی Lifecycle کاربران و دسترسی‌ها می‌تواند ریسک حساب‌های بلااستفاده، دسترسی بیش از حد و مدیریت پراکنده کاربران را کاهش دهد.
در این بخش سامانه احرازهویت یکپارچه کاربران می‌تواند با سیاست‌های MFA، Least Privilege و Access Review ترکیب شود.

مدیریت Credentialهای حساس

رمزهای حساب‌های مدیریتی، سرورها، سرویس‌ها و تجهیزات شبکه باید تحت کنترل قرار گیرند.
استفاده از سامانه مدیریت رمز همراه با Rotation، Audit و محدودسازی دسترسی می‌تواند بخشی از معماری Privileged Access Security باشد.

کنترل تبادل فایل

استفاده کارکنان از ایمیل شخصی، سرویس‌های عمومی Cloud یا پیام‌رسان برای انتقال فایل می‌تواند Visibility سازمان را کاهش دهد.
یک سامانه انتقال امن فایل می‌تواند مسیر رسمی تبادل فایل را ایجاد کند و قابلیت‌هایی مانند Authentication، Encryption، Logging و سیاست دسترسی را در اختیار سازمان قرار دهد.

کنترل انتشار اطلاعات سازمانی

انتشار اطلاعات نیز باید فرایند مشخص داشته باشد. چه کسی اجازه انتشار دارد؟ چه محتوایی نیازمند تأیید است؟ چه رویدادهایی ثبت می‌شوند؟
در این زمینه سامانه انتشار امن پورتال سازمانی می‌تواند بخشی از کنترل انتشار و دسترسی به محتوای سازمان باشد.

تفکیک شبکه‌های حساس

Network Segmentation می‌تواند حرکت جانبی مهاجم را محدود کند.
در زیرساخت‌های خاص، رویکردهای جداسازی اینترنت از اینترنت نیز ممکن است برای تفکیک محیط‌های حساس از شبکه‌های عمومی یا محیط‌های با سطح اعتماد متفاوت در نظر گرفته شوند. طراحی این معماری باید براساس نیاز سازمان، معماری شبکه و Risk Assessment انجام شود.

شاخص‌های مهم برای سنجش مدیریت حوادث سایبری

برای بهبود Incident Response باید عملکرد آن اندازه‌گیری شود.

MTTD

Mean Time to Detect نشان می‌دهد به‌طور متوسط چقدر طول می‌کشد تا Incident شناسایی شود.
کاهش MTTD به معنای افزایش توان Detection است.

MTTR

MTTR بسته به تعریف سازمان ممکن است به Mean Time to Respond یا Mean Time to Recover اشاره کند.
این شاخص مدت زمان لازم برای واکنش یا بازیابی را نشان می‌دهد.

تعداد Incidentها براساس Severity

مقایسه تعداد حوادث Low، Medium، High و Critical می‌تواند روند تغییر وضعیت امنیت را نشان دهد.

نرخ تکرار Incident

تکرار یک Incident مشابه می‌تواند نشان دهد Root Cause قبلی به‌درستی رفع نشده است.

مدت Downtime

میزان توقف سرویس‌ها یک KPI مهم برای سنجش Impact تجاری Incident است.

درصد حوادث شناسایی‌شده توسط کنترل‌های داخلی

این شاخص مشخص می‌کند چه تعداد از Incidentها توسط SOC، SIEM، EDR یا سایر سازوکارهای داخلی کشف شده‌اند و چه تعداد ابتدا توسط کاربر یا شخص ثالث گزارش شده‌اند.

اشتباهات رایج در مدیریت حوادث امنیتی

برخی اشتباهات می‌توانند خسارت یک Incident را افزایش دهند.

نداشتن Incident Response Plan

در زمان بحران افراد نمی‌دانند چه کاری باید انجام دهند و تصمیم‌ها با تأخیر گرفته می‌شوند.

مشخص نبودن مسئول حادثه

نبود Incident Owner یا Incident Commander می‌تواند باعث سردرگمی میان تیم‌ها شود.

اعتماد کامل به Backup

Backup بدون آزمایش Recovery تضمین نمی‌کند که اطلاعات در روز حادثه قابل بازیابی باشند.

Logging ناکافی

بدون Log مناسب ممکن است مسیر حمله و دامنه نفوذ قابل تشخیص نباشد.

ایزوله کردن دیرهنگام سیستم آلوده

تأخیر در Containment می‌تواند فرصت Lateral Movement را افزایش دهد.

حذف شواهد

پاک کردن فایل، فرمت سیستم یا Shutdown عجولانه ممکن است Evidence مهم را از بین ببرد.

رفع نکردن Root Cause

Restore کردن سرویس بدون اصلاح Vulnerability یا Credential آسیب‌دیده احتمال تکرار Incident را افزایش می‌دهد.

نداشتن مانور

Incident Response Plan باید با Tabletop Exercise و سناریوهای عملی آزمایش شود.

تمرکز صرف بر ابزار

خرید ابزار بدون تعریف Policy، Process و مسئولیت‌ها معمولاً نتیجه مطلوبی ایجاد نمی‌کند.

چگونه برنامه مدیریت ریسک و حادثه سایبری سازمان را طراحی کنیم؟

برای ایجاد یک برنامه عملیاتی می‌توان مسیر زیر را دنبال کرد.

گام 1: دارایی‌های حیاتی را مشخص کنید

مشخص کنید توقف یا افشای کدام سیستم‌ها بیشترین خسارت را ایجاد می‌کند.

گام 2: Risk Assessment انجام دهید

تهدیدها، آسیب‌پذیری‌ها، Likelihood و Impact را بررسی کنید.

گام 3: Risk Register ایجاد کنید

برای هر ریسک موارد زیر را ثبت کنید:
•    شرح ریسک؛
•    Asset مرتبط؛
•    Likelihood؛
•    Impact؛
•    Risk Score؛
•    مالک ریسک؛
•    کنترل موجود؛
•    اقدام اصلاحی.

گام 4: کنترل‌ها را براساس ریسک انتخاب کنید

انتخاب کنترل باید نتیجه ارزیابی ریسک باشد، نه صرفاً محبوبیت یک فناوری.
برای نمونه:
•    برای مدیریت متمرکز هویت → سامانه احرازهویت یکپارچه کاربران
•    برای محافظت بهتر از Credentialها → سامانه مدیریت رمز
•    برای تبادل کنترل‌شده اطلاعات → سامانه انتقال امن فایل
•    برای کنترل انتشار سازمانی → سامانه انتشار امن پورتال سازمانی
•    برای کاهش ارتباط بخش‌های حساس → Network Segmentation و در معماری‌های متناسب، جداسازی اینترنت از اینترنت
در کنار این موارد، کنترل‌هایی مانند MFA، EDR، SIEM، Backup و Vulnerability Management نیز باید براساس Risk Profile انتخاب شوند.

گام 5: Incident Response Team ایجاد کنید

نقش و مسئولیت افراد را از قبل مشخص کنید.

گام 6: Incident Response Plan و Playbook تدوین کنید

سناریوهای مهم مانند موارد زیر باید Playbook مستقل داشته باشند:
•    Ransomware؛
•    Phishing؛
•    Data Breach؛
•    Account Compromise؛
•    Malware؛
•    DDoS؛
•    Network Intrusion.

گام 7: Logging و Monitoring را پیاده‌سازی کنید

حداقل باید رویدادهای مربوط به موارد زیر قابل بررسی باشند:
•    Authentication؛
•    تغییر Permission؛
•    فعالیت‌های مدیریتی؛
•    Endpoint؛
•    Firewall؛
•    انتقال فایل؛
•    تغییرات مهم سیستم.

گام 8: Backup و Disaster Recovery را آزمایش کنید

Restore باید در شرایط کنترل‌شده تمرین شود.

گام 9: Tabletop Exercise برگزار کنید

سناریوی واقعی طراحی کنید و از تیم‌ها بخواهید نحوه واکنش خود را تمرین کنند.

گام 10: Continuous Improvement داشته باشید

Risk Management و Incident Response فرایندهای یک‌باره نیستند.
پس از تغییر زیرساخت، ظهور تهدید جدید یا وقوع Incident باید برنامه بازبینی شود.

چک‌لیست آمادگی سازمان برای حوادث سایبری

•    دارایی‌های حیاتی شناسایی شده‌اند.
•    Risk Assessment انجام شده است.
•    Risk Register به‌روز است.
•    مالک هر ریسک مشخص است.
•    Incident Response Plan تدوین شده است.
•    Incident Response Team مشخص است.
•    Playbook حملات اصلی وجود دارد.
•    MFA برای حساب‌های حساس فعال است.
•    Lifecycle حساب‌های کاربری مدیریت می‌شود.
•    Credentialهای مدیریتی به‌صورت امن نگهداری می‌شوند.
•    مسیر رسمی و امن برای انتقال فایل وجود دارد.
•    انتشار اطلاعات سازمانی دارای فرایند کنترل‌شده است.
•    Network Segmentation متناسب با ریسک پیاده‌سازی شده است.
•    Log سیستم‌های حیاتی نگهداری می‌شود.
•    Monitoring امنیتی فعال است.
•    Backup آفلاین یا Immutable وجود دارد.
•    Recovery به‌صورت دوره‌ای آزمایش می‌شود.
•    RTO و RPO مشخص شده‌اند.
•    کانال ارتباط اضطراری تعریف شده است.
•    Tabletop Exercise انجام می‌شود.
•    Post-Incident Review اجرا می‌شود.
•    Lessons Learned وارد Risk Register می‌شوند.

سوالات متداول درباره مدیریت ریسک و حوادث امنیت سایبری

مدیریت ریسک امنیت سایبری چیست؟

مدیریت ریسک امنیت سایبری فرایند شناسایی دارایی‌ها، تهدیدها و آسیب‌پذیری‌ها و سپس ارزیابی احتمال و پیامد سناریوهای امنیتی است. هدف آن اولویت‌بندی ریسک‌ها و انتخاب کنترل‌های مناسب برای کاهش آنهاست.

مدیریت حادثه امنیتی چیست؟

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

اولین اقدام پس از شناسایی حمله سایبری چیست؟

ابتدا باید وقوع Incident اعتبارسنجی و Severity آن مشخص شود. سپس ضمن حفظ شواهد، اقدامات لازم برای جلوگیری از گسترش حمله انجام شود.

Incident Response Plan چیست؟

Incident Response Plan مشخص می‌کند هنگام وقوع حادثه چه افرادی مسئول هستند، مراحل Escalation چیست و چگونه Incident شناسایی، مهار، رفع و بازیابی می‌شود.

مراحل پاسخ به حادثه سایبری چیست؟

به‌طور کلی شامل آمادگی، شناسایی و تحلیل، مهار، حذف عامل تهدید، بازیابی و بررسی پس از حادثه است.

تفاوت مدیریت ریسک و مدیریت حادثه چیست؟

Risk Management بر شناسایی و کنترل ریسک پیش از تبدیل شدن آن به بحران تمرکز دارد. Incident Management بر حادثه‌ای تمرکز می‌کند که رخ داده یا در حال وقوع است.

NIST CSF 2.0 چیست؟

NIST CSF 2.0 چارچوبی برای مدیریت ریسک امنیت سایبری است که فعالیت‌ها را در شش Function اصلی Govern، Identify، Protect، Detect، Respond و Recover سازمان‌دهی می‌کند.

ارزیابی ریسک امنیت سایبری هر چند وقت یک‌بار باید انجام شود؟

Risk Assessment باید به‌صورت دوره‌ای و همچنین پس از تغییرات مهم زیرساخت، ورود فناوری جدید، وقوع Incident یا تغییر قابل‌توجه در Threat Landscape بازبینی شود.

آیا Backup برای مقابله با باج‌افزار کافی است؟

خیر. Backup بخش مهم Recovery است اما باید در کنار MFA، Patch Management، EDR، Network Segmentation، Monitoring و Incident Response استفاده شود. قابلیت Restore نیز باید آزمایش شود.

RTO و RPO چه تفاوتی دارند؟

RTO حداکثر زمان قابل‌قبول برای بازیابی یک سرویس است. RPO میزان قابل‌قبول از دست رفتن داده را بر اساس زمان مشخص می‌کند.

تیم Incident Response چه وظایفی دارد؟

این تیم Incident را تحلیل می‌کند، اقدامات Containment را هماهنگ می‌کند، شواهد را حفظ می‌کند، عامل تهدید را حذف می‌کند، Recovery را مدیریت می‌کند و Lessons Learned را ثبت می‌کند.

آیا ابزار امنیتی به تنهایی برای مدیریت ریسک کافی است؟

خیر. امنیت مؤثر به ترکیبی از Governance، Policy، Process، People و Technology نیاز دارد. ابزارهایی مانند SIEM، EDR یا سامانه‌های مدیریت هویت فقط زمانی بیشترین ارزش را دارند که در چارچوب یک برنامه مدیریت ریسک مشخص استفاده شوند.

جمع‌بندی؛ از مدیریت ریسک تا تاب‌آوری سایبری

مدیریت موفق امنیت سایبری زمانی شکل می‌گیرد که سازمان فقط به جلوگیری از حمله فکر نکند، بلکه کل چرخه شناخت ریسک، حفاظت، کشف، پاسخ و بازیابی را مدیریت کند.
Risk Assessment مشخص می‌کند چه دارایی‌هایی در معرض خطر هستند و کدام تهدیدها اولویت بیشتری دارند. کنترل‌های امنیتی احتمال وقوع یا شدت حادثه را کاهش می‌دهند. Monitoring و Detection امکان شناسایی سریع Incident را فراهم می‌کنند و Incident Response Plan کمک می‌کند سازمان هنگام بحران به‌جای تصمیم‌های پراکنده، براساس یک فرایند از قبل طراحی‌شده عمل کند.
در این میان، کنترل‌هایی مانند مدیریت هویت و دسترسی، حفاظت از Credentialها، انتقال کنترل‌شده فایل، انتشار امن اطلاعات، Network Segmentation، Logging، EDR، SIEM و Backup باید به‌عنوان اجزای یک معماری یکپارچه دیده شوند.
هدف نهایی نیز رسیدن به Cyber Resilience یا تاب‌آوری سایبری است؛ یعنی حتی اگر حمله‌ای رخ دهد، سازمان بتواند آن را سریع تشخیص دهد، دامنه خسارت را محدود کند، سیستم‌های حیاتی را بازیابی کند و از تجربه حادثه برای افزایش آمادگی آینده استفاده کند.