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