چگونه نتایج خود را در جلسه SOC توضیح دهم؟

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

ساختار جلسه ارائه حادثه

از هرم وارونه استفاده کنید: نتیجه‌گیری را ابتدا ارائه دهید، سپس آن را پشتیبانی کنید. یک مدیر یا رهبر آن‌شب که وارد جلسه شما می‌شود باید در ده ثانیه اول جواب این سؤال را بیابد که "آیا ما نقض‌شده‌ایم و آیا باید اقدام کنم" نه اینکه در دقیقه ششم در جزئیات packet capture گم شود.

ساختار قابل استفاده:

1. چه اتفاقی افتاد — یک جمله. "یک ایستگاه کاری در بخش مالی یک ماکرو بدخواه را اجرا کرد و به یک IP خارجی متصل شد."
2. تاثیر تاکنون — دامنه، سیستم‌های تحت تأثیر، داده‌های برخورد یا عدم برخورد.
3. آنچه ما انجام داده‌ایم — ایزوله‌سازی، بلوکه‌کردن، مراحل محدودیت‌سازی که قبلاً انجام شده‌اند.
4. آنچه ما نیاز داریم — تصمیمات، منابع یا تصویب‌هایی از افراد حاضر.
5. خط‌الزمان — فهرستی کوتاه از نظر زمانی برای کسانی که جزئیات می‌خواهند، جدا از عنوان.

فرآیند تحقیق خود را بیان نکنید ("ابتدا کنسول EDR را بررسی کردم، سپس به گزارش DNS چرخش دادم") مگر اینکه کسی خاص بپرسد چگونه به آنجا رسیدید. این روش شما است، نه مشکل آنها. برای گزارش کتوب‌شده یا پیگیری متخصص آن را ذخیره کنید.

نوشتن انتقال‌های وظیفه‌ای که بافت را از دست نمی‌دهند

انتقال شیفت به دلیل بیش‌تر از هر دلیل دیگری ناکام می‌شود: تحلیل‌گر خروجی فرض می‌کند که تحلیل‌گر ورودی زمینه‌ای را یادی می‌کند که فقط در ذهن وی وجود دارد. انتقال وظیفه را طوری بنویسید انگار خواننده هیچ خاطری از شیفت ندارد.

یک یادداشت انتقال خوب شامل:

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

مثالی از یک خط انتقال ضعیف: "به هشدار روی HOST-2231 نگاه کردم، مریب به نظر می‌آید، فردا بررسی می‌کنم."

مثالی از یک خط قوی: "HOST-2231 قانون Sigma را برای دسترسی LSASS توسط باینری بدون امضا فعال کرد (proc: update.exe, hash: 3f2c...). با EDR تایید شد که هیچ تخلیه حافظه‌ای رخ نداده. کاربر تا ساعت 9 صبح غیر موجود است — هنوز مصاحبه‌ای نشده. مرحله بعد: prefetch و sched task artefacts را بکشید، اگر باینری با variant شناخته‌شده Mimikatz مطابقت کند به IR اسکیل دهید."

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

سؤالات سناریوی مصاحبه: آنها واقعاً چه تست می‌کنند

وقتی مصاحبه‌کننده می‌گوید "با من کاوش کنید چگونه هشدار phishing را تحقیق می‌کنید" آنها نمی‌دانند آیا نام‌های ابزار صحیح را می‌شناسید یا نه. آنها بررسی می‌کنند آیا شما یک فرآیند تکراری دارید و آیا می‌توانید استدلال خود را تحت فشار خفیفی بلند کنید — که دقیقاً همانی است که یک شیفت واقعی نیاز دارد.

جواب خود را همانطور ساختار دهید که خود حادثه را ساختار می‌دهید:

• اولویت triage خود را ابتدا بیان کنید (آیا این محدود است، آیا در حال گسترش است، آیا نامزد false positive است)
• artefacts خاصی را نام ببرید که می‌کشیدید (email headers، sender reputation، URL sandbox detonation، mailbox rules changes)
• بگویید چه چیزی مرحله بعدی شما را تغییر می‌دهد ("اگر sandbox detonation یک credential harvesting page نشان دهد، فوری auth موفق را از آن کاربر در 24 ساعت گذشته بررسی می‌کنم")
• با معیارهای escalation بپایان رسانید — چه چیزی باعث می‌شود این را یک حادثه تایید‌شده بخوانید در مقابل بستن آن به عنوان بی‌ضرر

مصاحبه‌کنندگان متوجه می‌شوند وقتی نامزدها با مطلق‌گویی و بدون منطق شاخه‌ای صحبت می‌کنند. تحقیقات واقعی شرطی هستند: "اگر X، سپس Y؛ اگر نه، سپس Z." نشان دادن این شاخه‌ای ارزش‌مندتر است از تکرار هر منبع گزارش‌ی که تا به حال شنیده‌اید.

ترجمه برای stakeholders غیر تخنیکی

مدیر مالی نیاز ندارد "lateral movement از طریق pass-the-hash برای domain controller را بشنود." آنها نیاز دارند "یک مهاجم از اعتبارات دزدی‌شده برای تلاش در رسیدن به سیستمی استفاده کرد که دسترسی را برای کل شرکت کنترل می‌کند؛ ما آن را قبل از موفقیت بلوکه کردیم." نسخه فنی را در یک appendix یا doc پیگیری برای افرادی که می‌پرسند دسترس‌پذیر نگاه‌دارید، اما مکالمات را با تأثیر تجاری plain-language شروع کنید: پول، downtime، data exposure، regulatory exposure.

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

برای اطلاعات بیشتر در مورد ساختار incident writeups و interview prep مخصوص نقش‌های blue team، segmentهای Korra Studio در report writing و SOC analyst interview practice را بررسی کنید.