با حوصله بخوان، مثالها را تحلیل کن و تمرینها را انجام بده؛ هدف حفظ کردن تعریفها نیست
Severity و محدوده را مشخص کن
محدوده مشکل مشخص میکند چند کاربر، دستگاه، شبکه یا سرویس تحت تأثیر هستند؛ مقایسه یک نمونه سالم و خراب سریعترین راه کوچک کردن محدوده است قبل از دانستن محدوده سراغ تغییر سراسری نرو راهنمای CISA و NIST بر چند پایه تکرارشونده تأکید دارد: استفاده از MFA برای حسابهای مهم، بهروزرسانی منظم، محدود کردن دسترسی مدیریتی، نگهداری Backup قابل بازیابی، ثبت رویدادها و آموزش مقابله با فیشینگ؛ در رخداد مشکوک، هدف اول حفظ شواهد و محدود کردن دامنه اثر است، نه انجام تغییرهای متعدد و بدون ثبت؛ حسابهای مدیریتی باید از حساب روزمره جدا باشند و سطح دسترسی فقط به اندازه نیاز کاری داده شود پایش مؤثر فقط جمع کردن عدد و Log نیست؛ باید وضعیت عادی سرویس شناخته شود، Metricهای معنادار انتخاب شوند و Alert زمانی ایجاد شود که نیاز به اقدام دارد؛ Syslog چارچوبی برای انتقال پیامهای رویداد ارائه میدهد و SNMP برای مشاهده و مدیریت بسیاری از تجهیزات شبکه استفاده میشود؛ همگام بودن زمان سیستمها برای ارتباط دادن رویدادهای چند دستگاه ضروری است و Log باید در کنار وضعیت سرویس و تغییرات همان بازه تحلیل شود
طبق Procedure دستگاه را محدود کن
در هشدار امنیتی اگر سیاست سازمان Isolation را لازم میداند دستگاه را از مسیر تعیینشده محدود کن؛ کابلکشیدن یا خاموش کردن کور ممکن است شواهد را از بین ببرد یا واکنش تیم امنیت را مختل کند راهنمای CISA و NIST بر چند پایه تکرارشونده تأکید دارد: استفاده از MFA برای حسابهای مهم، بهروزرسانی منظم، محدود کردن دسترسی مدیریتی، نگهداری Backup قابل بازیابی، ثبت رویدادها و آموزش مقابله با فیشینگ؛ در رخداد مشکوک، هدف اول حفظ شواهد و محدود کردن دامنه اثر است، نه انجام تغییرهای متعدد و بدون ثبت؛ حسابهای مدیریتی باید از حساب روزمره جدا باشند و سطح دسترسی فقط به اندازه نیاز کاری داده شود پایش مؤثر فقط جمع کردن عدد و Log نیست؛ باید وضعیت عادی سرویس شناخته شود، Metricهای معنادار انتخاب شوند و Alert زمانی ایجاد شود که نیاز به اقدام دارد؛ Syslog چارچوبی برای انتقال پیامهای رویداد ارائه میدهد و SNMP برای مشاهده و مدیریت بسیاری از تجهیزات شبکه استفاده میشود؛ همگام بودن زمان سیستمها برای ارتباط دادن رویدادهای چند دستگاه ضروری است و Log باید در کنار وضعیت سرویس و تغییرات همان بازه تحلیل شود
کاربر و Process و زمان را ثبت کن
در هشدار امنیتی نام کاربر، Process، زمان، مسیر فایل و اقدام EDR را ثبت کن؛ قبل از حذف شواهد یا خاموش کردن ابزار امنیتی، موضوع را طبق فرایند رخداد بررسی یا ارجاع کن راهنمای CISA و NIST بر چند پایه تکرارشونده تأکید دارد: استفاده از MFA برای حسابهای مهم، بهروزرسانی منظم، محدود کردن دسترسی مدیریتی، نگهداری Backup قابل بازیابی، ثبت رویدادها و آموزش مقابله با فیشینگ؛ در رخداد مشکوک، هدف اول حفظ شواهد و محدود کردن دامنه اثر است، نه انجام تغییرهای متعدد و بدون ثبت؛ حسابهای مدیریتی باید از حساب روزمره جدا باشند و سطح دسترسی فقط به اندازه نیاز کاری داده شود پایش مؤثر فقط جمع کردن عدد و Log نیست؛ باید وضعیت عادی سرویس شناخته شود، Metricهای معنادار انتخاب شوند و Alert زمانی ایجاد شود که نیاز به اقدام دارد؛ Syslog چارچوبی برای انتقال پیامهای رویداد ارائه میدهد و SNMP برای مشاهده و مدیریت بسیاری از تجهیزات شبکه استفاده میشود؛ همگام بودن زمان سیستمها برای ارتباط دادن رویدادهای چند دستگاه ضروری است و Log باید در کنار وضعیت سرویس و تغییرات همان بازه تحلیل شود
شواهد را پاک نکن
شواهد داده قابل مشاهده مانند پیام خطا، Log، نتیجه تست، وضعیت Port یا تنظیمات فعلی هستند؛ هر فرضیه باید با شواهد تأیید یا رد شود حدس و تجربه شخصی مفیدند اما جای شواهد را نمیگیرند راهنمای CISA و NIST بر چند پایه تکرارشونده تأکید دارد: استفاده از MFA برای حسابهای مهم، بهروزرسانی منظم، محدود کردن دسترسی مدیریتی، نگهداری Backup قابل بازیابی، ثبت رویدادها و آموزش مقابله با فیشینگ؛ در رخداد مشکوک، هدف اول حفظ شواهد و محدود کردن دامنه اثر است، نه انجام تغییرهای متعدد و بدون ثبت؛ حسابهای مدیریتی باید از حساب روزمره جدا باشند و سطح دسترسی فقط به اندازه نیاز کاری داده شود پایش مؤثر فقط جمع کردن عدد و Log نیست؛ باید وضعیت عادی سرویس شناخته شود، Metricهای معنادار انتخاب شوند و Alert زمانی ایجاد شود که نیاز به اقدام دارد؛ Syslog چارچوبی برای انتقال پیامهای رویداد ارائه میدهد و SNMP برای مشاهده و مدیریت بسیاری از تجهیزات شبکه استفاده میشود؛ همگام بودن زمان سیستمها برای ارتباط دادن رویدادهای چند دستگاه ضروری است و Log باید در کنار وضعیت سرویس و تغییرات همان بازه تحلیل شود
رخداد را سریع Escalate کن
رخداد اختلال یا کاهش کیفیت یک سرویس است و هدف اولیه بازگرداندن سرویس است؛ یک راهحل موقت امن میتواند قبل از علت اصلی استفاده شود رخداد با Problem که علت زیربنایی را دنبال میکند یکی نیست راهنمای CISA و NIST بر چند پایه تکرارشونده تأکید دارد: استفاده از MFA برای حسابهای مهم، بهروزرسانی منظم، محدود کردن دسترسی مدیریتی، نگهداری Backup قابل بازیابی، ثبت رویدادها و آموزش مقابله با فیشینگ؛ در رخداد مشکوک، هدف اول حفظ شواهد و محدود کردن دامنه اثر است، نه انجام تغییرهای متعدد و بدون ثبت؛ حسابهای مدیریتی باید از حساب روزمره جدا باشند و سطح دسترسی فقط به اندازه نیاز کاری داده شود پایش مؤثر فقط جمع کردن عدد و Log نیست؛ باید وضعیت عادی سرویس شناخته شود، Metricهای معنادار انتخاب شوند و Alert زمانی ایجاد شود که نیاز به اقدام دارد؛ Syslog چارچوبی برای انتقال پیامهای رویداد ارائه میدهد و SNMP برای مشاهده و مدیریت بسیاری از تجهیزات شبکه استفاده میشود؛ همگام بودن زمان سیستمها برای ارتباط دادن رویدادهای چند دستگاه ضروری است و Log باید در کنار وضعیت سرویس و تغییرات همان بازه تحلیل شود
فرض کن در سناریوی واقعی شرکت مشکلی گزارش شده و احتمال میدهی به سناریو: هشدار امنیتی روی Client مربوط باشد. قبل از تغییر، وضعیت فعلی را با ابزارهای مرتبط با همان سناریو و مستندات شرکت بررسی میکنی و نتیجه را با یک حالت سالم یا مستند معتبر مقایسه میکنی. اگر شواهد فرضیه را تأیید کردند، فقط همان بخش مرتبط را تغییر میدهی و بعد همان تست را دوباره اجرا میکنی تا مطمئن شوی مشکل واقعاً برطرف شده است
این اشتباهها را تکرار نکن
- در هشدار امنیتی اگر سیاست سازمان Isolation را لازم میداند دستگاه را از مسیر تعیینشده محدود کن؛ کابلکشیدن یا خاموش کردن کور ممکن است شواهد را از بین ببرد یا واکنش تیم امنیت را مختل کند
- در هشدار امنیتی نام کاربر، Process، زمان، مسیر فایل و اقدام EDR را ثبت کن. قبل از حذف شواهد یا خاموش کردن ابزار امنیتی، موضوع را طبق فرایند رخداد بررسی یا ارجاع کن
- تغییر دادن تنظیمات مرتبط با سناریو: هشدار امنیتی روی Client قبل از اینکه مطمئن شوی مشکل واقعاً به همین بخش مربوط است
حالا خودت انجام بده
- در یک نمونه آزمایشی مرتبط با سناریو: هشدار امنیتی روی Client، فقط وضعیت فعلی را مشاهده کن و سه نکتهای را که برای تشخیص حالت سالم مهماند یادداشت کن
- با ابزارهای مرتبط با همان سناریو و مستندات شرکت وضعیت مرتبط با سناریو: هشدار امنیتی روی Client را بدون تغییر بررسی کن، سه داده واقعی جمع کن و توضیح بده هرکدام چه چیزی به تو میگویند
- یک خطای فرضی مرتبط با سناریو: هشدار امنیتی روی Client بنویس و مشخص کن اولین تست کمخطر تو چیست و چه نتیجهای فرضیهات را رد میکند
نکتههایی که باید با خودت ببری
- Severity و محدوده را مشخص کن
- طبق Procedure دستگاه را محدود کن
- کاربر و Process و زمان را ثبت کن
- شواهد را پاک نکن
- رخداد را سریع Escalate کن
- در هر مرحله فقط یک تغییر کنترلشده انجام بده تا اثر آن قابل تشخیص باشد
قبل از رفتن به درس بعد، جواب را برای خودت توضیح بده
چرا باید Severity و محدوده را مشخص کنی و از کجا میفهمی نتیجه درست است؟
محدوده مشکل مشخص میکند چند کاربر، دستگاه، شبکه یا سرویس تحت تأثیر هستند؛ مقایسه یک نمونه سالم و خراب سریعترین راه کوچک کردن محدوده است
چرا باید طبق Procedure دستگاه را محدود کنی و از کجا میفهمی نتیجه درست است؟
در هشدار امنیتی اگر سیاست سازمان Isolation را لازم میداند دستگاه را از مسیر تعیینشده محدود کن؛ کابلکشیدن یا خاموش کردن کور ممکن است شواهد را از بین ببرد یا واکنش تیم امنیت را مختل کند
چرا باید کاربر و Process و زمان را ثبت کنی و از کجا میفهمی نتیجه درست است؟
در هشدار امنیتی نام کاربر، Process، زمان، مسیر فایل و اقدام EDR را ثبت کن. قبل از حذف شواهد یا خاموش کردن ابزار امنیتی، موضوع را طبق فرایند رخداد بررسی یا ارجاع کن
برای ذخیره پیشرفت، دوره را رسمی شروع کن
با ثبتنام، تکمیل درسها و نمره آزمون روی حساب ذخیره میشود
