OpenCTI چیست و چه مسئله‌ای را حل می‌کند؟
OpenCTI یک محیط برای سازمان‌دهی دانش درباره تهدیدهای سایبری است. فرض کنید تیم امنیت شما یک گزارش درباره بدافزار، چند نشانی دامنه، نتیجه بررسی یک فایل و یادداشت تحلیلگر را در چهار محل متفاوت نگهداری می‌کند. پیدا کردن ارتباط میان این داده‌ها دشوار می‌شود، به‌ویژه وقتی چند ماه بعد همان نشانی یا روش حمله دوباره دیده شود. هدف چنین سامانه‌ای این است که اطلاعات به موجودیت‌های مشخص و رابطه‌های قابل بررسی تبدیل شوند. به این ترتیب می‌توان از یک گزارش به بدافزار مربوط رسید و سپس منابعی را دید که ارتباط آن بدافزار با یک فعالیت مشخص را مطرح کرده‌اند. ارزش اصلی، حفظ زمینه و منبع ادعاست؛ صرفاً زیاد شدن تعداد نشانی‌های ذخیره‌شده ارزش اطلاعاتی ایجاد نمی‌کند.
برای استفاده درست باید میان «داده»، «اطلاعات» و «تحلیل» تفاوت بگذارید. مشاهده یک دامنه در ترافیک، داده است. دانستن اینکه این دامنه در یک گزارش معتبر ذکر شده، به آن زمینه می‌دهد. نتیجه‌گیری درباره اینکه آیا ارتباط مشاهده‌شده برای سازمان شما خطرناک بوده، تحلیل جداگانه‌ای می‌خواهد. OpenCTI می‌تواند در نگهداری و پیوند این لایه‌ها کمک کند، اما نباید هر رابطه ترسیم‌شده را یک واقعیت قطعی دانست. نمودار زیبا جای بررسی شواهد را نمی‌گیرد. این نکته برای کاربر تازه‌کار اهمیت ویژه دارد، چون ظاهر منظم یک پایگاه دانش ممکن است قطعیتی بیش از کیفیت واقعی داده‌ها القا کند.
جایگاه آن در کنار SIEM و ابزار پاسخ‌گویی
برای طراحی یک میزکار امنیتی، نقش ابزارها را جدا تعریف کنید. SIEM معمولاً رویدادهای عملیاتی را جمع‌آوری و تحلیل می‌کند؛ سامانه مدیریت رخداد به پیگیری کارهای پاسخ‌گویی کمک می‌کند؛ پایگاه اطلاعات تهدید زمینه‌ای درباره تهدیدها و ارتباطات آن‌ها فراهم می‌سازد. ممکن است این سامانه‌ها با یکدیگر داده ردوبدل کنند، اما نباید بدون بررسی ظرفیت و هدف، همه لاگ‌های خام را وارد پایگاه دانش کرد. حجم انبوه رویدادهای تکراری می‌تواند جست‌وجوی دانش معتبر را دشوار کند. بهتر است خروجی تحلیل‌شده یا مشاهده‌ای که برای تصمیم مشخص اهمیت دارد، همراه با ارجاع به محل نگهداری شواهد وارد شود.
مثلاً اگر یک هش فایل در یک میزبان دیده شده است، پاسخ اولیه شامل بررسی مالک میزبان، مسیر فایل، زمان اجرا و رفتار واقعی آن است. پایگاه اطلاعات تهدید ممکن است گزارش‌های پیشین مربوط به همان هش را نشان دهد. این زمینه برای اولویت‌بندی مفید است، ولی نتیجه «این میزبان آلوده است» فقط از یک تطبیق به دست نمی‌آید. ممکن است فایل در قرنطینه، مخزن نمونه یا محیط آزمایش قرار داشته باشد. خروجی خوب، تصمیمی است که هم اطلاعات بیرونی و هم وضعیت واقعی دارایی داخلی را در نظر گرفته باشد.
موجودیت، مشاهده و شاخص را اشتباه نگیریم
موجودیت می‌تواند گزارشی تحلیلی، یک نرم‌افزار مخرب، سازمان، روش یا زیرساخت مرتبط با تهدید باشد. رابطه توضیح می‌دهد دو موجودیت چگونه به هم مربوط‌اند. در مستندات OpenCTI، بخش‌های مختلفی برای تحلیل‌ها، مشاهدات، تهدیدها و دانش زمینه‌ای در نظر گرفته شده است. برای شروع لازم نیست تمام مدل را یاد بگیرید؛ کافی است یک مثال محدود را درست مدل کنید. یک گزارش با عنوان روشن بسازید، منبع اصلی را ثبت کنید و موجودیت‌هایی را که واقعاً در آن گزارش وجود دارند به آن پیوند دهید. بهتر است سه ارتباط مستند داشته باشید تا سی ارتباطی که از حدس یا شباهت اسم ساخته شده‌اند.
یک observable مانند نشانی IP یا دامنه، لزوماً شاخص مخرب بودن نیست. ممکن است نشانی مربوط به میزبانی مشترک باشد یا مالک آن تغییر کند. شاخص تشخیص نیز به منطق، زمینه و بازه اعتبار نیاز دارد. هنگام تبدیل مشاهده به اقدام عملیاتی، دلیل اهمیت، زمان مشاهده و میزان اطمینان را بررسی کنید. اگر دامنه‌ای فقط در متن یک گزارش به عنوان مثال آمده است، وارد کردن آن به فهرست مسدودسازی اشتباه است. در تمرین آموزشی از نام‌ها و نشانی‌های مخصوص مثال استفاده کنید تا داده آزمایشگاهی با اطلاعات عملیاتی اشتباه نشود.
یک تمرین عملی برای آغاز کار
یک گزارش عمومی و معتبر درباره یک رخداد تاریخی انتخاب کنید و ابتدا آن را بیرون از ابزار بخوانید. فهرستی کوتاه از پرسش‌ها بنویسید: چه چیزی مشاهده شده، چه کسی آن را گزارش کرده، زمان رخداد چیست و کدام بخش نتیجه‌گیری نویسنده است؟ سپس در محیط آزمایش OpenCTI، گزارش را با عنوان و تاریخ مناسب ثبت کنید. ارجاع بیرونی را به صفحه اصلی گزارش بدهید. اگر تاریخ انتشار و تاریخ مشاهده متفاوت‌اند، آن‌ها را در توضیح روشن کنید. این کار از اشتباه رایجی جلوگیری می‌کند که تاریخ ورود داده به سامانه به جای تاریخ رخداد استفاده می‌شود.
در گام بعد فقط دو یا سه موجودیت مرتبط را اضافه کنید و برای هر رابطه بنویسید چه شاهدی آن را پشتیبانی می‌کند. یک تحلیلگر دیگر باید بتواند بدون گفت‌وگوی شفاهی با شما، از رابطه به منبع برسد. سپس همان موضوع را با جست‌وجو پیدا کنید و بررسی کنید آیا نام‌ها و برچسب‌ها منسجم‌اند. اگر یک موجودیت با دو املای متفاوت ایجاد شده، پیش از وارد کردن داده بیشتر مسئله نام‌گذاری را حل کنید. پایان این تمرین زمانی است که یک پرسش مشخص، مثلاً «چه گزارش‌هایی این روش را مطرح کرده‌اند؟»، با پاسخ قابل پیگیری همراه شود.
Connector چه کاری انجام می‌دهد؟
اتصال‌دهنده‌ها راه ورود، غنی‌سازی یا خروج داده را فراهم می‌کنند. نوع کار آن‌ها یکسان نیست: یک اتصال‌دهنده می‌تواند اطلاعات یک منبع بیرونی را دریافت کند، دیگری درباره یک موجودیت اطلاعات تکمیلی بخواهد و موردی دیگر داده را برای مصرف در سامانه بعدی آماده کند. بنابراین پیش از فعال‌سازی، جهت حرکت داده و هزینه آن را مشخص کنید. دسترسی به یک سرویس بیرونی ممکن است به کلید، سهمیه درخواست یا مجوز استفاده نیاز داشته باشد. داشتن خود OpenCTI به معنی دسترسی نامحدود به تمام منابع اطلاعاتی نیست.
برای راه‌اندازی اولیه، یک منبع کوچک و شناخته‌شده انتخاب کنید. زمان‌بندی دریافت، برچسب‌های ورودی، حجم مورد انتظار و مالک اتصال را ثبت کنید. پس از اولین اجرا، صرفاً سبز بودن وضعیت فرایند کافی نیست؛ چند داده ورودی را باز کنید و کیفیت فیلدها را ببینید. آیا منبع اصلی حفظ شده؟ تاریخ‌ها معنی درست دارند؟ آیا نام سازمان با نام ابزار اشتباه شده است؟ افزودن چندین اتصال هم‌زمان عیب‌یابی را سخت می‌کند، زیرا مشخص نمی‌شود کدام منبع داده تکراری یا ناقص ایجاد کرده است. بهتر است هر اتصال با یک نمونه قابل بررسی پذیرفته شود.
کیفیت داده و اعتماد به منابع
دو گزارش مستقل درباره یک موضوع، ارزش متفاوتی با دو نسخه بازنشرشده از یک گزارش دارند. هنگام ارزیابی اطمینان، تعداد لینک‌ها را با تعداد شواهد مستقل برابر نگیرید. ممکن است پنج وب‌سایت همگی یک خبر اولیه را تکرار کرده باشند. در یادداشت تحلیلی روشن کنید که نتیجه از مشاهده مستقیم آمده یا از تحلیل یک ناشر دیگر. اگر میان منابع اختلاف وجود دارد، اختلاف را ثبت کنید. پاک کردن ابهام از متن، آن را از واقعیت حذف نمی‌کند؛ فقط خواننده بعدی را از محدودیت دانش بی‌خبر می‌گذارد.
برچسب‌گذاری نیز باید محدود و قابل توضیح باشد. برچسب‌هایی مانند «مهم» بدون تعریف مشترک، پس از مدتی کاربرد خود را از دست می‌دهند. برای یک تیم کوچک، بهتر است واژه‌نامه‌ای شامل حوزه مرتبط، وضعیت بررسی و منشأ داده داشته باشید. این واژه‌نامه لازم نیست پیچیده باشد، اما باید مشخص کند چه کسی اجازه افزودن برچسب جدید دارد. هنگام ادغام موارد مشابه، رابطه‌ها و ارجاعات قدیمی را بررسی کنید؛ تشابه نام کافی نیست. یک ابزار قانونی ممکن است در گزارش تهدید آمده باشد، اما این به معنی مخرب بودن همه استفاده‌های آن ابزار نیست.
دسترسی، محرمانگی و مرز انتشار
اطلاعات تهدید همیشه عمومی نیست. گزارش داخلی ممکن است نام مشتری، نشانی میزبان، نمونه فایل یا جزئیات رخدادی در حال بررسی را داشته باشد. پیش از اتصال خروجی به سرویس دیگر، تعیین کنید کدام داده مجاز به انتشار است. حسابی که فقط برای مشاهده نیاز دارد نباید دسترسی مدیریتی دریافت کند. همچنین کلید اتصال‌دهنده را مانند رمز سرویس نگهداری کنید و در یادداشت یا مخزن عمومی قرار ندهید. در آزمایش دسترسی، تنها صفحه فهرست را بررسی نکنید؛ جزئیات موجودیت، فایل ضمیمه و خروجی گرفتن نیز باید با سطح دسترسی مورد انتظار مطابقت داشته باشند.
برای تیمی که اطلاعات را با همکاران بیرونی به اشتراک می‌گذارد، یک گزارش آزمایشی با داده ساختگی بسازید و مسیر خروج آن را بررسی کنید. ببینید آیا یادداشت داخلی همراه داده بیرون می‌رود یا خیر. این آزمایش از آن جهت مفید است که افراد معمولاً روی دسترسی صفحه اصلی تمرکز می‌کنند و مسیرهای جانبی را فراموش می‌کنند. سیاست نگهداری نیز باید روشن باشد: چه کسی می‌تواند اطلاعات قدیمی را حذف کند، چه چیزی باید به دلیل نیاز تحلیلی بماند و نسخه پشتیبان تا چه مدتی نگهداری می‌شود. پاسخ این پرسش‌ها را مطابق نیاز واقعی سازمان بنویسید.
سنجش موفقیت و رفع اشکال
موفقیت را با تعداد موجودیت‌ها به تنهایی اندازه نگیرید. معیار بهتر می‌تواند زمان لازم برای پیدا کردن منبع یک ادعا، درصد رابطه‌های دارای شاهد یا تعداد پرسش‌های عملیاتی باشد که پاسخ مستند گرفته‌اند. اگر تحلیلگران برای هر جست‌وجو با ده‌ها نتیجه بی‌ربط روبه‌رو می‌شوند، افزایش حجم داده کمکی نکرده است. یک بازبینی دوره‌ای کوتاه از چند گزارش تصادفی نشان می‌دهد آیا کیفیت رو به بهبود است یا فقط انبار داده بزرگ‌تر شده. همچنین باید میان «منبع اطلاعاتی فعال است» و «داده مفید و تازه وارد می‌شود» تفاوت بگذارید.
وقتی داده جدید دیده نمی‌شود، مسیر را مرحله‌ای بررسی کنید: دسترسی منبع بیرونی، اجرای اتصال‌دهنده، پردازش پیام و ثبت موجودیت. اگر اتصال به دلیل سهمیه متوقف شده، اجرای مکرر دستی ممکن است مشکل را تشدید کند. اگر موجودیت وارد شده اما پیدا نمی‌شود، فیلتر، بازه زمانی و مجوز مشاهده را بررسی کنید. هر بار تنها یک فرضیه را آزمایش کنید و نمونه مشخصی از داده مورد انتظار داشته باشید. عبارت کلی «چیزی نمی‌آید» برای عیب‌یابی کافی نیست؛ شناسه یک گزارش، زمان درخواست و محل توقف، مسیر تشخیص را کوتاه می‌کند.
نگهداری و استفاده بلندمدت
برای استقرار واقعی، ظرفیت ذخیره‌سازی و نسخه پشتیبان را با حجم داده انتخاب کنید و تغییر نسخه را در محیط جداگانه بیازمایید. یک نسخه پشتیبان فقط زمانی اطمینان‌بخش است که بازیابی آن تمرین شده باشد؛ دیدن فایل آرشیو به تنهایی کافی نیست. سازگاری اتصال‌دهنده‌ها با نسخه پلتفرم را نیز پیش از ارتقا بررسی کنید. قابلیت‌های بعضی بخش‌ها ممکن است میان ویرایش‌ها یا نسخه‌ها تفاوت داشته باشند، بنابراین راهنمای نصب همان نسخه را مبنا قرار دهید. این مقاله یک مسیر مفهومی و آموزشی ارائه می‌کند و جایگزین جزئیات استقرار نسخه انتخابی شما نیست.
در نهایت، OpenCTI زمانی بیشترین فایده را دارد که تیم بداند چه پرسشی را دنبال می‌کند. برای مثال «کدام روش‌های گزارش‌شده با دارایی‌های ما ارتباط دارند؟» پرسش روشن‌تری از «همه داده‌ها را جمع کنیم» است. از یک گردش کار کوچک شروع کنید: دریافت یک گزارش، ثبت منبع، ساخت رابطه مستند، بررسی همکار و مصرف نتیجه در یک تصمیم دفاعی. پس از قابل اعتماد شدن این چرخه، منابع و کاربران بیشتری اضافه کنید. چنین رشد تدریجی باعث می‌شود پایگاه دانش قابل فهم بماند و هر عضو تازه تیم بتواند دلیل حضور داده‌ها و معنای ارتباط‌ها را دنبال کند.
