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

برای تحقق این مأموریت، عملیات SOC را می‌توان به چهار مرحله‌ی عملیاتی تقسیم کرد:

مشاهدات ارزیابی: چالش‌های رایج در مراکز عملیات امنیتی (SOC)

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

جمع‌آوری لاگ

در این مرحله، سه مشکل اصلی به‌طور مکرر دیده شده است:

1. نبود پوشش قابلیت دید بر اساس چارچوب  MITRE D3FEND/DETT&CT
   بسیاری از سازمان‌ها، ماتریس پوشش قابلیت دید تهدیدات را نگهداری نمی‌کنند و به جای آن، منابع لاگ را صرفاً در فایل‌هایی مانند Excel لیست می‌کنند که ردیابی و مدیریت آن دشوار است. این یعنی آن‌ها رویکردی نظام‌مند برای اینکه چه داده‌ای وارد SIEM می‌شود و چه تکنیک‌ها و تاکتیک‌هایی (TTPs) قابل شناسایی هستند، ندارند. همچنین حفظ مداوم این ماتریس هم چالش‌برانگیز است، زیرا منابع لاگ ممکن است به دلایل مختلف از بین بروند؛ از جمله: حذف عامل‌ها، تغییر تنظیمات مقصد لاگ، یا تعویض تجهیزات مانند فایروال. این امر منجر به کاهش کیفیت ماتریس دید لاگ‌ها می‌شود.
2. استفاده ناکارآمد از داده‌ها برای همبست‌سازی[1]
   در بسیاری از موارد، داده‌های مناسب برای شناسایی تهدیدات در دسترس است، اما هیچ قانون همبست‌سازیبرای بهره‌برداری از آن وجود ندارد. این یعنی داده هست، ولی استفاده‌ای از آن نمی‌شود.
3. وجود قوانین همبست‌سازی، اما بدون فیلدهای اطلاعاتی لازم
   گاهی اوقات، قوانین به درستی طراحی شده‌اند و منطق آن‌ها برای شناسایی تهدید مناسب است، اما داده‌های مورد نیاز از منابع لاگ به SIEM وارد نشده‌اند. این مانع از فعال شدن قوانین می‌شود. چنین مشکلی تنها از طریق ارزیابی کیفیت دادهقابل شناسایی است.

شناسایی تهدیدها

در این مرحله، در ارزیابی‌های انجام‌شده با مسائل زیر مواجه شده‌ایم:

1. اتکای بیش‌ازحد به قوانین پیش‌فرض فروشندگان
   بسیاری از سازمان‌ها به قوانین پیش‌فرض SIEM اکتفا می‌کنند و تنها زمانی این قوانین را تنظیم می‌کنند که هشدارها فعال شوند. از آنجا که محتوای پیش‌فرض بهینه‌سازی نشده است، معمولاً هزاران هشدار تولید می‌شود. این رویکرد واکنشی منجر به خستگی شدید از هشدارهامی‌شود و تمرکز تحلیلگران بر هشدارهای مهم را دشوار می‌کند.
2. عدم هم‌راستایی با پروفایل تهدیدهای سازمانی
   نبود یک پروفایل تهدید مشخص برای سازمان باعث می‌شود تمرکز بر تهدیدات واقعی و محتمل از بین برود. به‌جای آن، رویکردی پراکنده اتخاذ می‌شود؛ گویی در تاریکی تیراندازی می‌شود بدون اینکه هدف مشخص باشد.
3. استفاده ناموثر از فیدهای اطلاعات تهدید
   در برخی موارد، لاگ‌های Endpoint فاقد هش فایلهستند و فقط نام یا مسیر فایل گزارش می‌شود. این امر مانع از استفاده موثر از فیدهای TI می‌شود، زیرا داده‌ی کلیدی (هش) وارد SIEM نشده است.
4. خطا در پیاده‌سازی تحلیل‌ها
   یکی از چالش‌های جدی، پیاده‌سازی نادرست قوانینی است که در اصل به خوبی طراحی شده‌اند. این خطاها باعث می‌شوند با وجود تحلیل درست، تهدید شناسایی نشود. نبود فرآیند ساختارمند برای بررسی و اعتبارسنجی قوانین از دلایل اصلی این مشکل است.

بررسی و ارزیابی هشدار

مشکلات رایج در این مرحله عبارت‌اند از:

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

پاسخ به رخداد

چالش‌های این مرحله عمدتاً از مسائل مراحل قبلی نشأت می‌گیرند:

1. چالش در تعیین دامنه رخداد

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

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

در صورت تداوم این چالش‌ها، بی‌نظمی در عملیات SOC ادامه خواهد یافت. با ورود ابزارهای جدید امنیتی مانند CASB و امنیت کانتینر، که داده‌های تشخیص ارزشمندی تولید می‌کنند، و همچنین با پیشروی تحول دیجیتال، پیچیدگی عملیات امنیتی افزایش خواهد یافت و این مسائل را تشدید خواهد کرد.

اتخاذ رویکردی مؤثر و هدفمند

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

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

مزایای تقویت فرآیند تشخیص تهدید:

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

با تمرکز بر سرمایه‌گذاری در تشخیص تهدید و مدیریت ساختاریافته آن، سازمان‌ها می‌توانند به شکل چشم‌گیری عملکرد SOC را ارتقا داده و در برابر تهدیدهای پیچیده و در حال تکامل، مقاوم‌تر شوند. این مقاله تمرکز خود را تنها بر روی مدیریت تشخیص بر مبنای SIEM قرار داده است.

برنامه‌ی مهندسی تشخیص

پیش از ورود به جزئیات برنامه‌محور، ابتدا چرخه عمر مهندسی تشخیص تهدید را معرفی می‌کنیم که زیربنای این برنامه پیشنهادی را تشکیل می‌دهد.

چرخه عمر مهندسی تشخیص تهدید

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

عناصر کلیدی دخیل در طراحی یک برنامه‌ مهندسی تشخیص موفق:

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

تیم پشتیبانی‌کننده از برنامه مهندسی تشخیص

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

• خطای پیاده‌سازی به دلیل اختلاف در مدل داده‌ها میان تیم) DE کار با داده خام) و تیم SOC  (کار با داده‌های بهینه‌شده برای SIEM)
• تاخیر در انتشار قوانین تشخیص به‌ دلیل مشغله زیاد تیم SOC و عدم تمرکز روی وظایف DE

در نتیجه، این فرآیندها می‌توانند عملکرد تیم مهندسی تشخیص را تحت تأثیر قرار دهند.

تنها مسئولیتی که خارج از حوزه‌ی تیم DE قرار دارد، ورود لاگ‌هااست؛ چرا که نیازمند هماهنگی بین‌تیمی بوده و بهتر است همچنان تحت مدیریت تیم SOC باقی بماند تا تیم DE بتواند بر اهداف اصلی خود تمرکز کند.

حداقل نقش‌های کلیدی در تیم مهندسی تشخیص:

در شروع کار، تیم مهندسی تشخیص باید حداقل شامل سه نقش کلیدی زیر شود:

اندازه تیم مهندسی تشخیص

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

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

فرآیندها و رویه‌ها

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

• مسیر تحلیل تا انتشار را با کمترین خطا و بیشترین هماهنگی طی کنند
• خروجی‌های خود را با سایر بخش‌های SOC همسو سازند (مانند تیم پاسخ‌گویی به رخداد یا تیم مدیریت لاگ)
• بازخوردگیری از عملکرد قواعد و بهینه‌سازی مستمر را امکان‌پذیر سازند

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

 

فرآیندهای تست و اعتبارسنجی

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

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

اما صرفاً تست کافی نیست؛ باید یک فرآیند اعتبارسنجینیز در برنامه گنجانده شود که خارج از چرخه‌ی مهندسی تشخیص عمل کند. هدف این فرآیند، ارزیابی جامع کارایی برنامه است. این اعتبارسنجی می‌تواند توسط اعضای خارج از تیم DE یا حتی توسط یک ارائه‌دهنده‌ی خدمات خارجی انجام شود.

عناصر کلیدی در اعتبارسنجی مؤثر

یک فرآیند اعتبارسنجی مناسب باید شامل برنامه‌ریزی دقیق بر اساس:

• اطلاعات به‌روز تهدیدها
• پروفایل تهدید به‌روزرسانی‌شده سازمان

و در نهایت، باید گزارش‌هایی تولید کند که شامل موارد زیر باشند:

• نقاط قوت و عملکرد مطلوب برنامه
• حوزه‌هایی که نیاز به بهبود دارند
• شکاف‌های موجود در تشخیص تهدید

ابزارها

یکی از عناصر حیاتی در چرخه عمر مهندسی تشخیص، ابزارهایی هستند که فرآیندها را تسهیل کرده و بهره‌وری تیم را افزایش می‌دهند. ابزارهای کلیدی عبارت‌اند از:

• سیستم تیکتینگ:
  برای مدیریت مؤثر گردش‌کارها، رهگیری پیشرفت تیکت‌ها از زمان ثبت تا بسته‌شدن، و استخراج متریک‌های زمانی جهت تحلیل کارایی.
• مخزن قوانین:
  بستری برای مدیریت کوئری‌ها و کدهای تشخیص که از مفهوم«شناسایی به عنوان کد»پشتیبانی می‌کند. این پلتفرم باید از فرمت‌های استانداردی مانند SIGMA پشتیبانی کرده و قابلیت‌هایی مانند مدیریت نسخه  و کنترل تغییرات  را ارائه دهد.
• پایگاه دانش متمرکز (Centralized Knowledge Base):
  فضایی برای مستندسازی قوانین تشخیص، توضیحات، نتایج تحقیقات، یادداشت‌ها و سایر اطلاعات مرتبط.
• بستر ارتباطی:
  ابزاری برای تسهیل همکاری میان اعضای تیم مهندسی تشخیص، ادغام با سیستم تیکتینگ، و دریافت نوتیفیکیشن‌های آنی درباره‌ی وضعیت تیکت‌ها یا سایر موارد مهم.
• محیط آزمایشگاهی:
  محیطی مجازی شامل SIEM و منابع داده‌ی مرتبط، همراه با ابزارهایی برای شبیه‌سازی حملات جهت انجام تست‌های پیش از انتشار قوانین تشخیص.

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

بهترین رویه‌ها در مهندسی تشخیص

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

 

۱. استانداردسازی نام‌گذاری قواعد تشخیص

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

مثلاً نام‌گذاری یک قانون به صورت:

«Suspicious file drop detected»

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

در حالی که یک نام کامل و ساختاریافته مثل:

Initial Access | Suspicious file drop detected in user directory | Windows – Medium

اطلاعات کلیدی را در همان نگاه اول به تحلیلگر ارائه می‌دهد. این نام‌گذاری به روشنی مشخص می‌کند که:

• در کدام مرحله از زنجیره حمله هشدار صادر شده: در این مثال، "Initial Access" مطابق با مدل MITRE ATT&CK یا Cyber Kill Chain است.
• محل وقوع رویداد مشکوک کجاست: "user directory" نشان می‌دهد که تعامل کاربر در این حمله دخیل بوده و این ممکن است شروع حمله باشد.
• پلت‌فرم هدف حمله چیست: "Windows" به تحلیلگر کمک می‌کند دستگاه مربوطه را سریع‌تر شناسایی کند.
• اولویت هشدار چقدر است: در این مثال، "Medium" مشخص شده، که تحلیلگر می‌تواند بر اساس آن هشدار را در اولویت قرار دهد.

برای اینکه این رویکرد به درستی کار کند، سطوح اولویت‌بندی در SIEM باید با سطوح تعریف‌شده توسط تیم مهندسی تشخیص همسو باشد.
یعنی اگر قانونی در DE با اولویت "High" تعریف شده، SIEM هم باید آن را به‌عنوان هشدار با اولویت "High" پردازش کند.

مزایای ساختار نام‌گذاری یکپارچه:

• تسهیل در جستجو، فیلتر و دسته‌بندی قوانین
• جلوگیری از تولید قوانین تکراری با اسامی مختلف
• افزایش سرعت تحلیل هشدارها توسط SOC
• انسجام بیشتر در مستندسازی و مدیریت قواعد

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

پایگاه دانش متمرکز

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

در ادامه، عناصر مهمی که باید در این پایگاه دانش گنجانده شوند آورده شده است:

مشخصات پایه قانون:

• نام قانون / شناسه یکتا / توضیح کوتاه
  به جهت شناسایی سریع و جلوگیری از ایجاد قوانین مشابه.

نوع و وضعیت قانون:

• نوع قانون: ایستا، همبسته، مبتنی برIoC، و غیره.
• وضعیت فعلی: آزمایشی، پایدار، بازنشسته و غیره.

شدت و اطمینان:

• Severity: میزان تهدیدی که این قانون پوشش می‌دهد.
• Confidence: احتمال اینکه یک هشدار ناشی از این قانون واقعاً مثبت باشد.

یادداشت‌های تحقیقاتی:

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

اجزای داده‌ای مورد استفاده:

• Log source و data fieldهایی که برای تشخیص رفتار استفاده شده‌اند.

اقدامات تریاژ:

• راهنمای گام‌به‌گام برای بررسی و تحلیل هشدارهای مرتبط.

سناریوهای هشدار مثبت کاذب:

• توصیف شرایطی که ممکن است منجر به هشدار نادرست شود.

برچسب‌ها:

• مثل: CVE, APT Actor, Malware Family, Kill Chain stage، و غیره.

این پایگاه دانش باید به‌طور کامل در دسترس همه تحلیلگران SOCباشد تا هم از قوانین استفاده کنند، هم در تحلیل‌های پیچیده‌تر از مستندات موجود بهره بگیرند.

برچسب‌ها

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

اقدامات تریاژ:

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

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

با داشتن این مستندسازی دقیق و برچسب‌گذاری مفهومی، تیم‌های SOC قادر خواهند بود تهدیدات را با دقت بیشتر شناسایی و نسبت به آن‌ها واکنش مؤثرتری نشان دهند.
این موضوع همچنین موجب افزایش کارایی تیم DEدر توسعه و بهینه‌سازی قوانین تشخیص و جلوگیری از هشدارهای کاذب می‌شود.

موتور استنتاج تکنیک‌های MITRE

MITRE یک پروژه به نام Technique Inference Engineدارد که مدلی برای درک تکنیک‌های دیگری است که یک مهاجم ممکن است بر اساس رفتار مشاهده‌شده از خود استفاده کند. این ابزار می‌تواند برای تیم‌های مهندسی تشخیص (DE)و تیم‌های SOCمفید باشد.

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

پایه‌گذاری

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

به‌عنوان مثال:

برای شناسایی T1480.002: Execution Guardrails: Mutual Exclusion sub-technique، MITRE توصیه می‌کند که یک کامپوننت داده‌ای مانند "ایجاد فایل" را نظارت کنید. طبق چارچوب منابع داده MITRE، کامپوننت‌های داده‌ای عبارتند از: اقدامات ممکن با اشیاء داده‌ای و یا وضعیت‌ها یا پارامترهای اشیاء داده‌ای که ممکن است برای تشخیص تهدیدات مرتبط باشند. این امر نشان می‌دهد که تشخیص دقیق نیاز به مستندسازی و درک زیرساخت و عملیات عادی سیستم‌ها دارد تا تیم‌ها قادر به شناسایی رفتار غیرعادی و مهاجمین واقعی باشند.

چرا بیس‌لاین مهم است؟

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

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

برای شناسایی فعالیت‌های مشکوک، یک قانون ساده می‌تواند نظارت بر رویدادهای ایجاد فایل قفل در پوشه /var/runباشد، که داده‌های موقت مربوط به عملیات در حال اجرای سرویس‌ها را ذخیره می‌کند. اما اگر در فرآیند بیس‌لاین متوجه شده‌اید که محیط شما از کانتینرها استفاده می‌کند که خود نیز فایل‌های قفل را برای مدیریت عملیات زمان اجرا ایجاد می‌کنند، می‌توانید رویدادهای مرتبط با کانتینر را فیلتر کنید تا از ایجاد هشدارهای کاذب جلوگیری کنید. این فیلتر به راحتی قابل اعمال است و به طور کلی می‌تواند شناسایی تهدیدات را با توجه به بیس‌لاین‌سازی زیرساخت‌هایی که تحت نظارت دارید، بهبود بخشد.

یافتن «راهروهای باریک» برای شناسایی تهدیدها

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

اولویت باید به تشخیص مبتنی بر رفتار داده شود، نه روش‌های مبتنی بر ابزار، نرم‌افزار یا شاخص‌های مبتنی بر تهدید (IoC). این رویکرد با مدل هرم درد[2]هم‌راستا است، که بر تشخیص مهاجمان بر اساس تاکتیک‌ها، تکنیک‌ها و رویه‌ها (TTPs) تأکید دارد، نه شاخص‌هایی که به راحتی قابل جایگزینی هستند. با اولویت دادن به TTPهای مشترک، می‌توانیم به طور مؤثر عمل‌کرد مهاجم را شناسایی کنیم، که این امر باعث می‌شود تشخیص تهدیدات مقاوم‌تر و مؤثرتر باشد.

قوانین جهانی برای تشخیص تهدیدات

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

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

جمع‌بندی

1. بیس‌لاین‌سازی زیرساخت‌ها به کاهش هشدارهای کاذب کمک می‌کند و باعث می‌شود که تشخیص تهدیدات به شکل دقیق‌تری انجام شود.
2. تشخیص مبتنی بر رفتار و تمرکز بر TTPها باعث مقاوم‌تر شدن برنامه تشخیص و افزایش دقت آن می‌شود.
3. قوانین جهانی که به طور پیش‌فرض در SIEM موجود هستند باید در مراحل اولیه عملیاتی شوند و به مرور زمان بر اساس نیازهای خاص سازمان تنظیم گردند.

این اصول کمک می‌کنند تا تیم‌های تشخیص تهدید، به ویژه در SOC‌ها، با دقت بیشتر تهدیدات را شناسایی کرده و زمان واکنش به آن‌ها را کاهش دهند.

برخی از نمونه‌ها عبارتند از:

1. شناسایی تغییرات تنظیمات فایروال ویندوز
2. استفاده از ابزارهای دسترسی از راه دور غیرمجاز
3. تعداد زیاد تلاش‌های ناموفق برای ورود به پایگاه‌داده

اندازه‌گیری عملکرد

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

طراحی معیارهای مؤثر سطح برنامه نیازمند بازبینی هدف اصلی از راه‌اندازی برنامه است. این رویکرد به شناسایی معیارهایی کمک می‌کند که موفقیت را به‌وضوح برای رهبری امنیتی ارتباط دهند. سه معیاری که می‌توانند برای اندازه‌گیری موفقیت در سطح برنامه بسیار مؤثر باشند عبارتند از:

1. زمان شناسایی (TTD) – این معیار به‌عنوان زمانی محاسبه می‌شود که از لحظه مشاهده اولین فعالیت مهاجم تا زمانی که به‌طور رسمی توسط تحلیل‌گر شناسایی می‌شود، سپری می‌شود. برخی از مراکز عملیات امنیتی (SOC) زمان فعال‌سازی هشدار در SIEM را به‌عنوان زمان شناسایی در نظر می‌گیرند، اما این معیار عملیاتی نیست. زمان تبدیل هشدار به یک حادثه بالقوه بهترین گزینه برای در نظر گرفتن زمان شناسایی توسط تحلیل‌گران SOC است.

گرچه شناسایی اولیه فعالیت در زمان t1 (زمان فعال‌سازی هشدار) رخ می‌دهد، زمانی که فعالیت مخرب اتفاق می‌افتد، باید یک سری رویدادها تجزیه و تحلیل شوند تا حادثه به‌طور صحیح واجد شرایط اعلام شود. به همین دلیل، t3برای تأیید دقیق شناسایی به‌عنوان تهدید بالقوه ضروری است. معیارهای اضافی مانند زمان برای بررسی (TTT)که مدت‌زمان لازم برای تأیید حادثه را مشخص می‌کند، و زمان برای تحقیق (TTI)که مدت‌زمان لازم برای بررسی حادثه تأیید شده را توصیف می‌کند، می‌توانند مفید باشند.

نسبت سیگنال به نویز (SNR)

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

جایی که:

• شناسایی‌های واقعی مثبت:مواردی که یک تهدید واقعی به‌درستی شناسایی شده است.
• هشدارهای منفی کاذب:هشدارهای نادرستی که تهدیدات واقعی را نشان نمی‌دهند.

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

هماهنگی با پروفایل تهدید (TPA)

این معیار ارزیابی می‌کند که شناسایی‌ها چقدر با تاکتیک‌ها، تکنیک‌ها و روش‌های شناخته شده تهدیدگران (TTPs) هماهنگ هستند. این معیار با تعیین تعداد TTPهای شناسایی شده که به‌طور مناسب توسط شناسایی‌های منحصر به فرد پوشش داده می‌شوند، این ارزیابی را انجام می‌دهد (مجموعه‌ای از اجزای داده منحصر به فرد).

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

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

 

• زمان برای تأیید شناسایی (TTQD):این معیار مدت‌زمان لازم برای تجزیه و تحلیل و اعتبارسنجی ارتباط یک شناسایی برای پردازش بیشتر را اندازه‌گیری می‌کند. مسئول مهندسی شناسایی، اهمیت شناسایی را ارزیابی کرده و آن را بر اساس اولویت‌بندی می‌کند. این معیار برابر با مدت‌زمانی است که از زمانی که تیکت برای ایجاد یک شناسایی باز می‌شود تا زمانی که برای تحقیقات بیشتر و پیاده‌سازی انتخاب می‌شود، گذشته است.
• زمان برای ایجاد شناسایی (TTCD):این معیار مدت‌زمان مورد نیاز برای طراحی، توسعه و پیاده‌سازی یک قانون شناسایی جدید را ردیابی می‌کند. این معیار چابکی فرآیندهای مهندسی شناسایی را در پاسخ به تهدیدات در حال تکامل نشان می‌دهد.

بک‌لاگ شناسایی

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

توزیع بحرانی بودن قوانین

• این معیار نشان‌دهنده نسبت قوانین شناسایی است که بر اساس سطح بحرانی آن‌ها طبقه‌بندی شده‌اند. این کمک می‌کند تا تعادل تمرکز بین شناسایی‌های با ریسک بالا و ریسک پایین‌تر درک شود.

پوشش شناسایی (MITRE)

• پوشش شناسایی بر اساس چارچوب MITRE ATT&CK نشان‌دهنده این است که چقدر قوانین شناسایی تاکتیک‌ها، تکنیک‌ها و روش‌های مختلف (TTPs) در چارچوب MITRE ATT&CK را پوشش می‌دهند. این کمک می‌کند تا شکاف‌های پوشش در استراتژی دفاعی شناسایی شود. توصیه می‌شود تعداد شناسایی‌های منحصر به فردی که هر تکنیک خاص را پوشش می‌دهند پیگیری شود، زیرا این امر دیدگاهی درباره هم‌راستایی پروفایل تهدید فراهم می‌کند – یک معیار در سطح برنامه. اگر شناسایی‌های منحصر به فرد برای شناسایی شکاف‌ها ایجاد نشوند و پوشش در طول زمان افزایش نیابد، این نشان‌دهنده مشکلی در فرآیند تأیید شناسایی است.

سهم قوانین که هیچ‌گاه فعال نشده‌اند

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

سایر معیارهای مرتبط

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

 

[1]Correlation

[2]Pyramid of Pain

 کسپرسکی آنلاین (ایدکو)

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