چگونه سامانه پایش و مدیریت رویدادهای امنیتی کسپرسکی، تصویر معناداری از لاگها برای مرکز عملیات امنیت میسازد؟
یک مرکز عملیات امنیت (SOC) ممکن است هر روز میلیونها لاگ و رویداد از فایروالها، نقاط پایانی، سرورها، Active Directory، نرمافزارهای سازمانی، تجهیزات شبکه، سرویسهای ابری و سامانههای امنیتی مختلف دریافت کند. روی کاغذ، این حجم داده باید به معنای دید بیشتر باشد؛ اما در عمل همیشه چنین نیست. اگر هر منبع فقط بخش مجزایی از ماجرا را نشان دهد، آنگاه کارشناس امنیت مجبور خواهد بود میان چندین کنسول، زمان ثبت رویدادها و دادههای پراکنده جابهجا شود تا بفهمد واقعاً چه اتفاقی افتاده است.
شاید یک تلاش برای ورود ناموفق اهمیت زیادی نداشته باشد. اجرای PowerShell نیز در بسیاری از سازمانها اتفاقی عادی است. برقراری ارتباط با یک سرور جدید هم الزاماً نشانه یک حمله نباشد. اما مسئله زمانی تغییر میکند که یک حساب کاربری در ساعتی غیرمعمول وارد شبکه شود، کمی بعد روی سامانهای دیگر دیده شود، سپس فرایندی خاص اجرا کند و در ادامه ارتباطی شکل بگیرد که با رفتار معمول آن سیستم همخوانی ندارد.
هرکدام از این رویدادها ممکن است بهتنهایی عادی به نظر برسند، اما کنار هم قرار گرفتن آنها میتواند داستان دیگری را نشان دهد. بنابراین مسئله اصلیSOC، فقط جمعآوری داده نیست. سؤال واقعی این است که چطور میتوان از هزاران رویداد مستقل، به تصویری رسید که نشان دهد در زیرساخت سازمان چه اتفاقی در حال رخ دادن است؟
مسئله SOC کمبود داده نیست؛ پراکندگی معناست
هر ابزار امنیتی، زیرساخت را از زاویه خودش میبیند. فایروال درباره ارتباطها و نشستهای شبکه اطلاعات میدهد، ابزارهای امنیت Endpoint اجرای پردازشها و فایلها را ثبت میکنند، Active Directory رفتار حسابهای کاربری را نشان میدهد و نرمافزارهای مختلف هم لاگهایی با ساختار و اصطلاحات مخصوص خود تولید میکنند. اگر کارشناس SOC بخواهد یک رخداد امنیتی را فقط با جستوجوی دستی در میان این منابع بررسی کند، بخش زیادی از زمانش صرف پیدا کردن ارتباط میان دادهها خواهد شد؛ نه تحلیل خود تهدید.
زیاد شدن تعداد رویدادها هم اولویتبندی را دشوارتر میکند. حتی ممکن است هشدارهای کماهمیت بیشتر شوند. رویدادهای تکراری، قالبهای متفاوت و هشدارهایی که اطلاعات کافی ندارند، میتوانند باعث شوند یک نشانه مهم میان حجم زیادی از دادهها گم شود.
مدیریت اطلاعات و رویدادهای امنیتی (SIEM-Security Information and Event Management) زمانی ارزش واقعی پیدا میکند که این اطلاعات پراکنده را به یک جریان منظم و قابل تحلیل تبدیل کند، نه اینکه فقط محلی برای ذخیره لاگها باشد.
از رویداد خام تا تصویری که قابل تحلیل باشد
Kaspersky Unified Monitoring and Analysis Platform یا KUMA دقیقا در همین نقطه وارد ماجرا میشود. کسپرسکی این محصول را در سبد فعلی سازمانی خود با عنوان Kaspersky SIEM معرفی میکند؛ سامانهای برای دریافت، پردازش، ذخیرهسازی، تحلیل و همبستگی دادههای امنیتی.
در معماری KUMA، اجزایی مانند Core، Agent، Collector، Event Router، Correlator و Storage هر کدام وظیفه مشخصی دارند. اینها نام رسمی اجزای محصول هستند و جدا بودن آنها این امکان را میدهد که معماری KUMA متناسب با اندازه و نیاز سازمان طراحی شود.
در مسیر پردازش داده، Collector پیامهای منابع مختلف را دریافت میکند و کارهایی مانند تجزیه، نرمالسازی و در صورت نیاز فیلتر یا تجمیع رویدادها را انجام میدهد.
Event Router میتواند دادههای پردازششده را بر اساس قواعد تعریفشده به مقصد مناسب هدایت کند. Correlator وظیفه تحلیل و همبستهسازی رویدادهای نرمالشده را بر عهده دارد و Storage دادههای لازم برای جستوجو و بررسیهای بعدی را ذخیره میکند. Core نیز بخش مدیریتی و رابط کاربری سامانه را در اختیار تیم امنیت قرار میدهد.
این تفکیک باعث میشود جمعآوری لاگ، تحلیل تهدید و ذخیرهسازی اطلاعات مجبور نباشند همگی در یک ساختار یکپارچه و غیرقابلتغییر قرار گیرند.
منابع ارسال کننده رویدادهای امنیتی به یک زبان صحبت نمیکنند
فرض کنید یک فایروال آدرس مبدأ را با یک نام مشخص ثبت میکند، نرمافزار دیگری همان اطلاعات را با ساختاری متفاوت ارسال میکند و Windows Event نیز قالب مخصوص خودش را دارد. ارتباط دادن این دادهها زمانی ممکن میشود که ابتدا همه آنها در یک ساختار مشترک قرار بگیرند.
KUMA این کار را در Collector انجام میدهد. رویداد خام پس از دریافت، توسط بخش نرمالسازی به یک ساختار استاندارد تبدیل میشود تا بخشهای دیگر سامانه بتوانند همه رویدادها را به یک شکل تحلیل کنند.
KUMA از قالبهای متداولی مانند JSON، CEF، Syslog، CSV، XML، NetFlow و IPFIX پشتیبانی میکند. هدف از این فرایند فقط تغییر شکل ظاهری داده نیست؛ اطلاعات باید به شکلی آماده شوند که بتوان بر اساس فیلدهای آنها جستوجو، فیلتر و همبستگی معنادار انجام داد.
در همین مرحله، بخشی از رویدادهای مشابه نیز میتوانند تجمیع شوند. تصور کنید یک تجهیز شبکه در مدت کوتاهی صدها رویداد تقریبا یکسان تولید کند. ارسال همه آنها با وزن برابر به مراحل بعدی نهتنها مفید نیست، بلکه میتواند حجم داده و نویز را افزایش دهد. قواعد تجمیع در KUMA میتوانند رویدادهای مشابه را بر اساس شرایط زمانی یا تعداد در قالب رویدادی خلاصهتر جمع کنند.
یک ورود غیرعادی فقط وقتی مهم میشود که قبل و بعدش را ببینیم
دوباره به سناریوی حساب کاربری برگردیم. کاربری ساعت سه بامداد وارد شبکه میشود. چند دقیقه بعد همان حساب روی سامانه دیگری مشاهده میشود. سپس پردازشی اجرا میشود که شاید بهتنهایی یک ابزار مدیریتی عادی باشد و کمی بعد ارتباط شبکهای جدیدی شکل میگیرد.
اگر برای هر اتفاق یک هشدار جداگانه ایجاد شود، کارشناس هنوز باید خودش ارتباط آنها را پیدا کند. اینجاست که همبستهسازی رویدادها اهمیت پیدا میکند.
Correlator در KUMA روی رویدادهای نرمالشده کار میکند و قواعد آن میتوانند توالی یا مجموعهای از شرایط را که از نظر امنیتی معنیدار هستند شناسایی کنند. در نتیجه، منطق تشخیص از «یک رویداد خاص اتفاق افتاد» به سمت «چند رفتار مرتبط در یک زمینه مشخص مشاهده شدند» حرکت میکند.
کسپرسکی همچنین محتوای تشخیصی خود را بهروزرسانی میکند تا قواعد همبستگی بتوانند بخشهای بیشتری از زنجیره رفتاری یک حمله را در کنار یکدیگر بررسی کنند. در نسخههای جدید KUMA، قابلیتهای تحلیل رفتار کاربر و موجودیتها (UEBA) نیز برای سناریوهایی مانند سوءاستفاده از حسابهای کاربری توسعه یافتهاند. در چنین مدلی میتوان عواملی مانند زمان غیرمعمول ورود، توالی غیرعادی رویدادها یا تلاشهایی برای دسترسی را که با رفتار همیشگی کاربر سازگار نیستند بررسی کرد. بنابراین معتبر بودن نام کاربری و رمز عبور الزاما به معنی عادی بودن رفتار آن حساب نیست.
هشدار باید شروع بررسی باشد، نه پایان آن
تولید هشدار زمانی ارزشمند است که کارشناس بتواند بفهمد چرا هشدار ایجاد شده است. در KUMA، فعال شدن یک قاعده همبستگی میتواند باعث ایجاد هشدار شود و رویدادهای مرتبط با آن نیز برای بررسی در دسترس باقی میمانند. کارشناس میتواند از خود هشدار به دادههایی برگردد که باعث ایجاد آن شدهاند و زنجیره رخداد را با جزئیات بیشتری بررسی کند. این موضوع تفاوت زیادی با حالتی دارد که کارشناس صرفا با جملهای مانند «فعالیت مشکوک شناسایی شد» روبهرو شود.
وقتی چند نشانه به یک مسئله بزرگتر اشاره میکنند، میتوان آنها را در قالب یک رخداد امنیتی واحد بررسی کرد. به این ترتیب، چند هشدار پراکنده میتوانند بخشی از یک موضوع مشترک در نظر گرفته شوند و مسئول مشخصی برای بررسی آن تعیین شود.
برای SOC که هر روز با تعداد زیادی هشدار سروکار دارد، این تغییر دیدگاه مهم است. تمرکز کار کارشناسان بهتر است روی «مسائل امنیتی» باشد، نه تکتک رویدادهایی که سامانهها تولید کردهاند.
بررسی رخداد همیشه از یک هشدار لحظهای شروع نمیشود
همه حملات در لحظه وقوع شناخته نمیشوند. گاهی یک نشانه نفوذ، دامنه مخرب یا اطلاعات تازهای درباره یک تهدید چند روز یا حتی چند هفته بعد منتشر میشود. در چنین شرایطی، تیم امنیت باید بتواند به دادههای گذشته برگردد و سؤال جدیدی از آنها بپرسد.
KUMA امکان جستوجو و بررسی رویدادهای ذخیرهشده را دارد. قابلیت Retroscan اجازه میدهد رویدادهای قدیمی دوباره در اختیار Correlator قرار بگیرند تا یک قاعده مشخص روی آنها اجرا شود.
این قابلیت فقط برای بررسی حمله مفید نیست. هنگام ساخت یا اصلاح یک قاعده تشخیصی نیز میتوان منطق آن را روی دادههای واقعی گذشته آزمایش کرد، بدون اینکه لازم باشد رفتار مشکوک دوباره در شبکه ایجاد شود.
در نسخههای جدیدتر، امکان اجرای جستوجوهای سنگین در پسزمینه نیز اضافه شده است تا تحلیل حجم زیادی از داده، کارهای روزمره کارشناس را متوقف نکند. برای SOCهایی که مدت زیادی داده نگهداری میکنند، همین تفاوت میتواند تعیین کند اطلاعات تاریخی فقط ذخیره شدهاند یا واقعا در زمان بررسی یک رخداد قابل استفاده هستند.
همچنین KUMA با نگاشت قواعد تشخیص به تاکتیکها و تکنیکهای چارچوب MITRE ATT&CK، به تیم امنیت کمک میکند جایگاه رفتارهای شناساییشده را در الگوهای شناختهشده حمله درک کند و بخشهایی را که به پوشش تشخیصی بیشتری نیاز دارند، شناسایی کند.
اطلاعات تهدید زمانی ارزش دارد که به رویداد متصل شود
دیدن یک آدرس IP، دامنه یا Hash در لاگ بهتنهایی اطلاعات زیادی به کارشناس نمیدهد. او باید بداند آیا این نشانه قبلا در منابع اطلاعات تهدید دیده شده است، چه سابقهای دارد و آیا ارتباط فعلی نیازمند بررسی بیشتری است.
KUMA میتواند رویدادها را با اطلاعات تکمیلی غنی کند. یکی از نمونههای رسمی آن، یکپارچهسازی با Kaspersky CyberTrace است.
در چنین شرایطی، اطلاعات مربوط به نشانههای تهدید میتواند در کنار دادههای رویداد قرار گیرد و در مراحل بعدی تحلیل، مورد استفاده قرار گیرد. در نتیجه، اطلاعات تهدید از یک سامانه جداگانه که کارشناس مجبور باشد دائما به آن مراجعه کند، به بخشی از جریان بررسی تبدیل میشود.
این موضوع زمانی اهمیت بیشتری پیدا میکند که یک قاعده تشخیصی فقط وجود یک ارتباط شبکهای را بررسی نکند، بلکه سابقه و اعتبار مقصد آن ارتباط را نیز در اختیار داشته باشد.
داشبورد باید به سؤالات عملیاتی پاسخ دهد
یک داشبورد پر از نمودار، لزوما به معنی دید بهتر نیست. مدیر SOC ممکن است بخواهد وضعیت هشدارهای مهم را ببیند. یک کارشناس به دنبال رویدادهای مرتبط با یک مبدا خاص باشد و تیم دیگری بخواهد وضعیت یک سناریوی تشخیصی مشخص را دنبال کند. بنابراین نمایش اطلاعات باید با نیاز کاربران مختلف سازگار باشد.
KUMA امکان ساخت داشبورد از نماها و پرسوجوهای مختلف را فراهم میکند. همچنین میتوان از اطلاعات خلاصه به جزئیات مرتبط رفت و بررسی دقیقتری انجام داد.
در چنین مدلی، داشبورد قرار نیست جای تحلیل کارشناس را بگیرد. وظیفه آن این است که نشانههای مهم را سریعتر در معرض دید قرار دهد و مسیر رسیدن از نمای کلی به جزئیات را کوتاهتر کند.
پاسخ خودکار باید به اندازه تشخیص قابلکنترل باشد
تشخیص تهدید بدون مسیر پاسخگویی میتواند صف هشدارها را طولانی کند؛ اما خودکارسازی بدون کنترل نیز ریسک خودش را دارد. هیچ سازمانی نمیخواهد یک قاعده اشتباه باعث شود اقدامی پرریسک بهصورت خودکار روی تعداد زیادی سیستم اجرا شود.
KUMA از قواعد پاسخگویی پشتیبانی میکند و یکی از روشهای موجود، اجرای Script بر اساس شرایط تعریفشده در قواعد همبستگی است. همچنین در برخی یکپارچهسازیها میتوان اقدامات پاسخگویی را به سایر اجزای زیرساخت امنیتی متصل کرد.
در عمل، سطح خودکارسازی باید با فرایند پاسخ به رخداد سازمان هماهنگ باشد. برای یک سناریو ممکن است ایجاد تیکت یا ارسال اعلان کافی باشد؛ در شرایط دیگر شاید اجرای یک اقدام فنی مشخص توجیه داشته باشد.
تفاوت در این است که خودکارسازی نباید بهعنوان میانبری بدون نظارت استفاده شود، بلکه باید بخشی از فرایند تعریفشده پاسخ به رخداد باشد.
معماری SIEM باید متناسب با حجم واقعی سازمان توسعه و گسترش پیدا کند
معماری مناسب برای شرکتی با چند صد سیستم لزوما برای سازمانی با چند مرکز داده، شعب متعدد و مجموعه بزرگی از منابع تولید لاگ مناسب نیست. حجم رویدادها، محل تولید داده، ظرفیت شبکه، مدت نگهداری اطلاعات و نوع جستوجوهایی که کارشناسان انجام میدهند همگی روی طراحی SIEM تأثیر میگذارند.
معماری مبتنی بر سرویسهای مجزای KUMA امکان پیادهسازی توزیعپذیر تمامی اجزای SIEM را فراهم میکند. در معماری محصول، قابلیتهایی برای توزیع بار، اجزای پشتیبان و نگهداری موقت داده در شرایطی که مقصد برای مدتی در دسترس نیست نیز در نظر گرفته شده است.
امکان استقرار چند Core در یک Cluster نیز برای افزایش دسترسپذیری و توسعهپذیری این بخش وجود دارد. البته این قابلیتها نیاز به طراحی ظرفیت را از بین نمیبرند.
تعداد رویداد در ثانیه، مدت نگهداری داده، میزان جستوجو، تعداد داراییها، ساختار شبکه و سناریوهای خرابی همچنان باید پیش از استقرار عملی بررسی شوند.
اتصال ابزارها مهم است؛ اما سناریوی امنیتی، از اتصال مهمتر است
SIEM معمولا در مرکز مجموعهای از محصولات امنیتی و زیرساختی از سازندگان مختلف قرار میگیرد. KUMA نیز برای دریافت رویداد از منابع متنوع از Agentها، رابطها و روشهای ارتباطی مختلف استفاده میکند.
روشهایی برای دریافت داده از Windows، فایلها، TCP، UDP، HTTP، Kafka و منابع دیگر وجود دارد.
اما صرف امکان اتصال یک سامانه به SIEM به این معنی نیست که جمعآوری داده آن ارزش عملی دارد. پیش از اضافه کردن هر منبع، بهتر است مشخص شود اطلاعات آن قرار است در کدام سناریوی تشخیص، بررسی رخداد یا الزام نظارتی استفاده شود.
در غیر این صورت سازمان هزینه جمعآوری، پردازش و نگهداری حجم زیادی از داده را پرداخت میکند که در عملیات واقعی SOC نقش مشخصی ندارد.
SIEM را نمیتوان صرفا از روی تعداد قابلیتها انتخاب کرد
مقایسه چند محصول SIEM در یک جدول و علامت زدن قابلیتهای آنها ساده است، اما تفاوت واقعی معمولا بعد از استقرار مشخص میشود.
آیا منابع مهم سازمان بهدرستی نرمالسازی میشوند؟ آیا سناریوهای تشخیصی موردنیاز SOC قابل پیادهسازی هستند؟ جستوجو و بررسی رخداد روی حجم واقعی داده چقدر عملی است؟ معماری محصول با ساختار شبکه و مدت نگهداری اطلاعات سازمان تطابق دارد؟ چه کسی قواعد تشخیصی را نگهداری میکند؟ پاسخ به رخداد چگونه با فرایندهای داخلی هماهنگ خواهد شد؟
KUMA قابلیتهایی مانند مدیریت لاگ و رویداد، نرمالسازی، همبستگی، جستوجوی تهدید، مدیریت هشدار و رخداد امنیتی، داشبورد، غنیسازی اطلاعات و پاسخگویی را در یک معماری قابل توسعه کنار هم قرار میدهد.
قابلیتهای جدیدتر مانند تحلیل رفتار کاربر و موجودیتها (UEBA) نیز نشان میدهند مسیر توسعه محصول فقط بر دریافت حجم بیشتر لاگ متمرکز نیست و ایجاد زمینه بیشتر برای تحلیل کارشناسان نیز بخش مهمی از آن است.
برای سازمانی که در مرحله انتخاب یا بازطراحی SIEM قرار دارد، قدم بعدی پیش از خرید محصول میتواند ارزیابی فنی با استفاده از منابع واقعی داده، چند سناریوی مهم امنیتی، حجم تقریبی رویدادها و فرایندهای فعلی SOC باشد تا تصویر دقیقتری از مناسب بودن راهکار ارائه دهد.
برگزاری جلسه معرفی محصول و یا اجرای یک نصب آزمایشی نیز میتواند مشخص کند KUMA در معماری واقعی سازمان چگونه رفتار میکند، چه میزان پیکربندی لازم دارد و کدام بخشهای طراحی باید پیش از استقرار نهایی اصلاح شوند.
شرکت ایمن آزما افزار با ارائه خدمات مشاوره تخصصی، طراحی معماری، ارائه دموی محصول، انجام نصب آزمایشی و پیادهسازی محصول Kaspersky Unified Monitoring and Analysis Platform (KUMA)، آماده همکاری با سازمانها برای توسعه و بهبود زیرساخت پایش و مدیریت رخدادهای امنیتی میباشد.
برای بررسی دقیقتر KUMA متناسب با ساختار شبکه و نیازهای SOC سازمان خود، میتوانید با همکاران ما در ارتباط باشید.