روند پاسخ حادثه

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

روند پاسخ حادثه ، در سطح بالایی ، شامل موارد زیر است:

تشخیص و تجزیه و تحلیل

فعالیت حادثه پس از

آماده سازی

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

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

تشخیص و تجزیه و تحلیل

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

بخش تشخیص این مرحله غالباً نتیجه نظارت یا هشدار بر اساس خروجی یک ابزار یا خدمات امنیتی خواهد بود. این ممکن است از یک سیستم تشخیص نفوذ (IDS) ، نرم افزار ضد ویروس (AV) ، سیاهههای مربوط به فایروال ، سیاهههای مربوط به پروکسی ، هشدار از ابزار امنیتی و نظارت بر رویداد (SIEM) در صورتی که برنامه داخلی یا ارائه دهنده خدمات امنیتی مدیریت شده (MSSP) باشد ، باشد. اگر برنامه خارجی باشد ، یا هر یک از تعدادی از منابع مشابه.

بخش تجزیه و تحلیل این مرحله اغلب ترکیبی از اتوماسیون از یک ابزار یا خدمات ، معمولاً یک SIEM و قضاوت انسانی است. در حالی که ما اغلب می توانیم از نوعی آستانه استفاده کنیم تا بگوییم که تعداد X از وقایع در مدت زمان معینی طبیعی است یا اینکه ترکیبی خاص از وقایع طبیعی نیست (دو ورود ناموفق به دنبال موفقیت و به دنبال آن تغییر رمز عبور ، دنبال می شود. به عنوان مثال ، با ایجاد یک حساب جدید) ، ما اغلب هنگام بحث در مورد پاسخ حادثه ، مداخله انسان را در یک نقطه خاص می خواهیم. چنین مداخلات انسانی غالباً شامل بررسی خروجی سیاهههای مربوط توسط دستگاههای مختلف امنیتی ، شبکه و زیرساخت ها ، تماس با طرفی است که گزارش این حادثه و ارزیابی کلی اوضاع را نشان می دهد. اگر شما تیمی از تحلیلگران 24 × 7 را اداره کنید ، این می تواند گران باشد ، بنابراین اتوماسیون هرچه بیشتر عملکردهای مهم مهم است.

هنگامی که کنترل کننده حادثه اوضاع را ارزیابی می کند ، آنها در مورد اینکه آیا این مسئله یک حادثه را تشکیل می دهد یا خیر ، تعیین می کنند ، ارزیابی اولیه در مورد بحران این حادثه (در صورت وجود) ، و با هرگونه منابع اضافی مورد نیاز برای ادامه مرحله بعدی تماس بگیرید. بشر

مهار ، ریشه کن کردن و بهبودی

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

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

در حین ریشه کن کردن ، ما سعی خواهیم کرد تا اثرات مسئله را از محیط خود حذف کنیم. در مورد سرور آلوده به بدافزار ، ما قبلاً سیستم را جدا کرده و آن را از شبکه فرمان و کنترل آن جدا کرده ایم. اکنون باید بدافزار را از سرور حذف کنیم و اطمینان حاصل کنیم که در جای دیگری از محیط ما وجود ندارد. این ممکن است شامل اسکن اضافی میزبان های دیگر در محیط باشد تا اطمینان حاصل شود که بدافزار وجود ندارد ، و بررسی سیاهههای مربوط به سرور و فعالیتهای دستگاههای حمله کننده در شبکه به منظور تعیین اینکه چه سیستم های دیگری سرور آلوده در ارتباط بوده استبا. با بدافزار ، به ویژه بدافزار یا انواع بسیار جدید ، این می تواند یک کار دشوار برای اطمینان از تکمیل صحیح باشد. دشمن دائماً در حال توسعه اقدامات متقابل به جدیدترین ابزارها و روشهای امنیتی است. هر وقت شک در مورد اینکه آیا بدافزارها یا مهاجمان واقعاً از محیط ما بیرون رانده شده اند ، باید در ضمن تعادل تأثیر عملیات ، به طرف احتیاط اشتباه کنیم. هر رویداد نیاز به ارزیابی ریسک دارد.

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

فعالیت حادثه پس از

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

بیشتر بخوانید URL: https://www.sciencedirect.com/science/article/pii/b9780128007440000014

اصول مؤلفه امنیتی برای ارزیابی

رسیدگی به حادثه

"روند پاسخ حادثه چندین مرحله دارد. مرحله اولیه شامل ایجاد و آموزش یک تیم پاسخ به حادثه و دستیابی به ابزارها و منابع لازم است. در حین آماده سازی ، سازمان همچنین تلاش می کند تا با انتخاب و اجرای مجموعه ای از کنترل ها بر اساس نتایج ارزیابی ریسک ، تعداد حوادثی را که رخ می دهد محدود کند. با این حال ، ریسک باقیمانده پس از اجرای کنترل ، ناگزیر خواهد بود. بنابراین تشخیص نقض امنیتی برای هشدار دادن به سازمان در هر زمان که حوادث رخ دهد ، لازم است. با توجه به شدت این حادثه ، سازمان می تواند با داشتن آن و در نهایت بهبودی از آن ، تأثیر این حادثه را کاهش دهد. در طی این مرحله ، فعالیت اغلب به تشخیص و تجزیه و تحلیل باز می گردد - برای مثال ، برای دیدن اینکه آیا میزبان های اضافی در هنگام ریشه کن کردن یک حادثه بدافزار به بدافزار آلوده می شوند. پس از انجام این حادثه به اندازه کافی ، سازمان گزارشی را صادر می کند که جزئیات علت و هزینه این حادثه را نشان می دهد و اقداماتی که سازمان باید برای جلوگیری از حوادث آینده انجام دهد. "13

آماده سازی

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

به عنوان یک ارزیابی کننده ظرفیت پاسخ به حادثه و فعالیت های مربوط به رسیدگی به حادثه ، درک این روند به خودی خود اغلب هرج و مرج است و می تواند در صورت فعال بودن پاسخ ، بی پروا ظاهر شود. یکی از زمینه های مهم برای تمرکز در طول بررسی ، آموزش مستند و تعریف شده برای پاسخ دهندگان و همچنین سیاست ها و رویه های سازمانی برای پاسخ به حادثه است. هر یک از این مناطق به تعیین موفقیت یا عدم موفقیت تیم پاسخ ، تعامل آنها با بقیه سازمان و در نهایت به حداقل رساندن تأثیر این حادثه بر سازمان ، مردم و رسالت آن کمک می کند.

تشخیص و تجزیه و تحلیل

وی گفت: "برای بسیاری از سازمانها ، چالش برانگیزترین بخش از روند پاسخ حادثه ، تشخیص دقیق و ارزیابی حوادث احتمالی است - تعیین می شود که آیا یک حادثه رخ داده است و اگر چنین است ، نوع ، میزان و بزرگی مشکل. آنچه این مسئله را بسیار چالش برانگیز می کند ترکیبی از سه عامل است:

حوادث ممکن است از طریق روشهای مختلف ، با سطح مختلف جزئیات و وفاداری ، تشخیص داده شود. قابلیت های تشخیص خودکار شامل IDPS مبتنی بر شبکه و میزبان ، نرم افزار آنتی ویروس و آنالایزرهای ورود به سیستم است. همچنین ممکن است حوادث از طریق وسایل دستی ، مانند مشکلات گزارش شده توسط کاربران ، شناسایی شود. برخی از حوادث دارای علائم آشکار هستند که به راحتی قابل تشخیص هستند ، در حالی که برخی دیگر تشخیص تقریباً غیرممکن است.

حجم علائم احتمالی حوادث به طور معمول زیاد است - به عنوان مثال ، برای یک سازمان غیر معمول نیست که هزاران یا حتی میلیون ها هشدار سنسور تشخیص نفوذ در روز دریافت کنند.

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

علائم یک حادثه در یکی از دو دسته قرار می گیرد: پیش سازها و شاخص ها. پیشرو نشانه این است که ممکن است یک حادثه در آینده رخ دهد. شاخص نشانه این است که ممکن است یک حادثه رخ داده باشد یا ممکن است اکنون اتفاق بیفتد.

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

حتی اگر یک شاخص دقیق باشد ، لزوماً به معنای وقوع یک حادثه نیست. برخی از شاخص ها ، مانند تصادف سرور یا اصلاح پرونده های مهم ، به دلایل مختلف به غیر از یک حادثه امنیتی از جمله خطای انسانی می توانند اتفاق بیفتند. با این حال ، با توجه به وقوع شاخص ها ، منطقی است که گمان کنیم که یک حادثه ممکن است رخ دهد و بر این اساس عمل کند. تعیین اینکه آیا یک واقعه خاص در واقع یک حادثه است ، گاهی اوقات موضوع قضاوت است. ممکن است برای تصمیم گیری با سایر پرسنل امنیتی فنی و اطلاعاتی لازم باشد. در بسیاری از موارد ، بدون توجه به اینکه مربوط به امنیت است ، باید به همان روش اداره شود. به عنوان مثال ، اگر سازمان هر 12 ساعت یکبار اتصال اینترنت را از دست می دهد و هیچ کس علت آن را نمی داند ، کارکنان می خواهند مشکل را به همان سرعت حل کنند و بدون توجه به علت آن ، از همان منابع برای تشخیص مشکل استفاده می کنند. "14

مهار ، ریشه کن کردن و بهبودی

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

استراتژی های مهار بر اساس نوع حادثه متفاوت است. به عنوان مثال ، استراتژی برای حاوی عفونت بدافزار ناشی از ایمیل کاملاً متفاوت از حمله DDOS مبتنی بر شبکه است. سازمان ها باید برای هر نوع حادثه اصلی استراتژی های مهار جداگانه ای ایجاد کنند ، با معیارهایی که برای تسهیل تصمیم گیری به وضوح ثبت شده است. "15

وی گفت: "پس از وقوع یک حادثه ، برای از بین بردن اجزای این حادثه ، مانند حذف بدافزار و غیرفعال کردن حساب های کاربری نقض شده و همچنین شناسایی و کاهش همه آسیب پذیری های مورد سوء استفاده ، ممکن است لازم باشد. در حین ریشه کن کردن ، شناسایی همه میزبان های آسیب دیده در سازمان بسیار مهم است تا بتوان آنها را اصلاح کرد. برای برخی از حوادث ، ریشه کن کردن یا لازم نیست یا در هنگام بهبودی انجام می شود.

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

ریشه کن کردن و بهبودی باید در یک رویکرد مرحله ای انجام شود تا مراحل اصلاح در اولویت قرار گیرد. برای حوادث در مقیاس بزرگ ، بهبودی ممکن است ماه ها طول بکشد. هدف مراحل اولیه باید افزایش امنیت کلی با تغییرات نسبتاً سریع (روزها تا هفته) برای جلوگیری از حوادث آینده باشد. مراحل بعدی باید بر تغییرات طولانی مدت (به عنوان مثال ، تغییر زیرساخت ها) و کار مداوم متمرکز شود تا شرکت تا حد امکان ایمن باشد. "16

فعالیت بعد از آن

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

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

به عنوان یک ارزیابی کننده پاسخ حادثه و ارزیاب ، شما به دنبال آموزش و مستندات تمرینی لازم برای هر پاسخ دهنده در تیم خواهید بود. سیاست های پاسخ به حادثه ، رسیدگی ، اطلاع رسانی و بررسی هیئت مدیره همه نیاز به شناسایی ، بررسی و ارزیابی دارند. روشهای پشتیبانی برای تلاش و تلاش برای پاسخگویی همه نیاز به بررسی و همبستگی با سیاستها ، کنترل های امنیتی IR از SP 800-53 و برنامه پاسخ واقعی حادثه برای هر سیستم همانطور که بررسی و ارزیابی می شود.