دوره آموزشی SEC504 – بخش دوم

آشنایی با مراحل Incident Handling

مراحل Incident Handling
فرآیند Incident Handling شامل شش مرحله می‌باشد که این مراحل عبارتند از:

Preparation
Identification
Containment
Eradication
Recovery
Lessons Learned

این مراحل به عنوان یک قطب‌نما یا نقشه راه برای Incident Handler‌ها در نظر گرفته می‌شوند. این مراحل به آن‌ها کمک می‌کنند تا بدانند چه می‌خواهند و چه کارهایی را باید انجام دهند.

Preparation
شانس واقعا به ذهن آماده کمک می‌کند و این در مورد برخورد با حادثه نیز درست است. توجه داشته باشید که در میان یک حادثه زمان خوبی برای درک فرآیند پاسخگویی به حادثه نمی‌باشد. اینکه در هنگام بروز حادثه باید از چه دستوراتی برای استخراج اطلاعات از سیستم عامل استفاده نمود و یا اینکه چطور می‌توان یک ایمیج فارنزیکی تهیه نمود، نحوه چگونگی انجام چنین مواردی باید از قبل مشخص شده باشد. بنابراین ضروری است که آمادگی لازم را برای مواجهه با حادثه داشته باشیم و مهارت‌های لازم برای آن را بیاموزیم.
هدف از مرحله Preparation این است که تیم را برای رسیدگی به حوادث آماده سازیم. مرحله Preparation دارای عناصر مختلفی است که در ادامه به آن‌ها می‌پردازیم. People، Policy، Data، Software/Hardware، Communications، Transportation، Space، Power and Environmental Control و Documentation عناصر مربوط به بخش Preparation می‌باشند.

People
در امنیت اطلاعات ما تمایل داریم تا بر موارد آسانی مانند IDS، IPS و آنتی ویروس‌ها تمرکز نماییم. این‌ها همه موارد فنی هستند و می‌توانند نسبتا به راحتی اجرا و پیاده سازی شوند. با این حال در بسیاری از موارد، این فناوری‌ها نمی‌توانند به ما بگویند که نفوذگران چگونه سازمان ما را مورد هدف قرار داده‌اند. بسیاری از نفوذگران به طور معمول آن چه را که ساده به نظر هم می‌آید مورد هدف قرار می‌دهند و آن چیزی نیست به جز People.
هنگامی که حمله به یک سازمان انجام می‌شود، نفوذگران ‌می‌توانند به چندین روش مختلف کاربران را مورد هدف قرار دهند. یکی از راه‌های رایج برای این موضوع استفاده از تماس تلفنی و یا ارسال یک ایمیل مخرب و آلوده است. بهترین روش برای آماده شدن برای این نوع از حملات، آموزش و ارزیابی مداوم می‌باشد.
بسیاری از ‌سازمان‌ها دارایی‌های تکنولوژیکی خود را در بازه‌های زمانی مختلف مورد ارزیابی قرار می‌دهند که این مورد ‌می‌تواند برای افراد نیز صورت گیرد. بدین صورت که با ایجاد یک کمپین مهندسی اجتماعی و یا استفاده از فریم ورک‌های فیشینگ، کاربران را مورد ارزیابی قرار دهیم که آیا برروی لینک‌های مخرب کلیک می‌کنند یا خیر. برای این منظور می‌توانید از ابزارهای sptoolkit، Phishme یا settoolkit استفاده نمایید. برای کسب اطلاعات بیشتر می‌توانید به لینک زیر از شرکت SANS مراجعه نمایید.

http://securingthehuman.org

Policy – Warning Banners
بنرهای هشدار دهنده برای یک Incident Handler بسیار حائز اهمیت می‌باشد. همه ‌می‌دانند که شما باید از این بنرها استفاده کنید ولی در برخی موارد ‌سازمان‌ها از این تکنیک استفاده نمی‌کنند. در این حالت شما باید به آن‌ها میزان اثر گذاری بنرهای هشدار دهنده را گوش زد نمایید. بنر یک ابزاری است که ‌می‌تواند به منظور تشریح خط مشی‌های سازمان شما مورد استفاده قرار‌گیرد.

بنرهای هشدار باید به کاربر توصیه کند که:

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

لازم به ذکر است باید مراقب قوانین حفظ حریم خصوصی کاربران نیز باشید. برای این کار پیشنهاد می‌شود از یک کارشناس حقوقی کمک بگیرید.

Policy – Response Strategies
در فرآیند پاسخگویی به حادثه اینکه آیا چیزی که اتفاق افتاده است به عنوان یک حادثه برای سازمان در نظر گرفته می‌شود یا خیر بسیار حائز اهمیت است. به همین دلیل باید یک رویکرد سازمانی برای پاسخگویی به حوادث وجود داشته باشد. بدین ترتیب در طول زمانی که یک حادثه اتفاق می‌افتد زمان بدی برای تصمیم‌گیری در این مورد است که آیا سیاست شما حفظ محرمانگی و یا اجرای قوانین بوده است. اکثر ‌سازمان‌ها به حفظ محرمانگی خود ادامه می‌دهند تا زمانی که مجبور به اجرای قوانین باشند. البته این سیاست همواره درست نیست.
در برخی موارد شما باید تنها ملاحظه کنید و یاد بگیرید. اگر این مورد را انجام می‌دهید احتمالا باید زمانی را برای مطالعه در مورد پروژه Honeynet در نظر بگیرید برای این کار می‌توانید به سایت honeynet.org مراجعه نمایید.

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

جهت روش‌تر شدن مبحث به موارد زیر دقت نمایید:
چه اتفاقی می‌افتد اگر داده‌های شما بر روی رایانه‌ای که شما مالک آن نیستید، قرار داشته باشد؟
به عنوان مثال کارمندی که در خانه کار می‌کند و یک سیستم در خانه دارد که برنامه‌های مرتبط با کسب و کار بر روی آن نصب شده و یا حتی داده‌هایی بر روی آن ذخیره شده است که مربوط به کسب و کار سازمان می‌باشد.
آیا کارمند باید این موضوع را به سازمان خود اطلاع دهد؟
آیا شما نمی‌خواهید یک نسخه پشتیبان کامل یا اصطلاحا Full Backup از آن تهیه کنید؟
بر روی سیستم اطلاعات سه سال مالی شرکت قرار دارد. آیا می‌خواهید ‌هارد‌دیسک را پاک نمایید؟
موضوع بعدی در مورد استفاده از VPN توسط کارمندان شما می‌باشد. شما باید از یک بنر هشدار که هنگام دسترسی به VPN نمایش داده می‌شود استفاده نمایید. در آن به کاربر هشدار ‌دهید که تمامی جستجو‌ها و فعالیت وی ثبت می‌شود و همچنین تمامی سیستم‌های متصل از طریق VPN موظف به جستجو از راه دور برای سازمان بوده و باید از قوانین مربوط به سازمان پیروی کنند.
این پیام یک ابتکار در حوزه اطلاع رسانی به کارمندان می‌باشد.
مورد بعدی در خصوص مشاوران سازمان می‌باشد. سازمان شما دارای یک مشاوری است که از آن بازدید می‌کند. رفتار شما در زمانی که از لپ تاپ وی یک اسکن به فایل سرور شما شناسایی شده است چگونه است؟
قطعا شما باید به آن رسیدگی کنید ولی آیا سیاستی را برای این موضوع در نظر گرفته اید؟
مورد بعدی امکان سرقت اطلاعات و تجهیزات است. اگر لپ تاپ یا سیستمی که اطلاعات سازمان برروی آن قرار دارد به سرقت برود، آیا سارق به کلیه اطلاعات دسترسی خواهد داشت؟ آیا شما برای این مورد هم آمادگی دارید؟
آیا شما از تکنیک‌های رمزنگاری استفاده می‌کنید؟
تمامی این موارد ذکر شده باید در سیاست‌های تدوین شده شما لحاظ گردد.