چگونه هزینه مالکیت یک سیستم SIEM را کاهش دهیم و چرا به مدیریت مرکزی لاگ (CLM) نیاز است

اخیراً، Splunk مدل صدور مجوز دیگری را اضافه کرده است - صدور مجوز مبتنی بر زیرساخت (حالا سه تا از آنها وجود دارد). آنها تعداد هسته‌های CPU در حال اجرا روی سرورهای Splunk را می‌شمارند. این بسیار شبیه به صدور مجوز Elastic Stack است، که در آن تعداد گره‌های Elasticsearch را می‌شمارند. سیستم‌های SIEM به طور سنتی گران هستند و شما معمولاً باید بین پرداخت هزینه زیاد و پرداخت هزینه زیاد یکی را انتخاب کنید. اما با کمی ابتکار، می‌توانید یک مجموعه مشابه را کنار هم قرار دهید.

به نظر دست و پا گیر می‌آید، اما گاهی اوقات این معماری در عمل جواب می‌دهد. پیچیدگی، امنیت را از بین می‌برد، و به طور کلی، همه چیز را از بین می‌برد. در واقع، برای چنین مواردی (من در مورد کاهش هزینه مالکیت صحبت می‌کنم)، یک کلاس کامل از سیستم‌ها وجود دارد - مدیریت مرکزی گزارش‌ها (CLM). این همان چیزی است که همه چیز در مورد آن است. گارتنر می‌نویسدبا توجه به اینکه آنها کم ارزش تلقی می‌شوند. در اینجا توصیه‌های آنها آمده است:

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

در این مقاله، ما در مورد تفاوت‌های رویکردهای صدور مجوز بحث خواهیم کرد، CLM را بررسی خواهیم کرد و یک سیستم خاص از این دسته را شرح خواهیم داد— Quest InTrustجزئیات زیر.

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

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

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

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

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

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

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

در نتیجه، سیستم‌های SIEM هدف نیازی به صرف توان اضافی CPU برای پردازش نخواهند داشت و می‌توانند از شناسایی تنها مهم‌ترین رویدادها بدون کاهش دید نسبت به آنچه اتفاق می‌افتد، بهره‌مند شوند.

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

آن راه‌حل میانی مرموز چیزی جز CLM نیست که در ابتدای این مقاله به آن اشاره کردم. گارتنر آن را اینگونه می‌بیند:

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

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

Quest InTrust از یک سیستم ذخیره‌سازی اختصاصی با فشرده‌سازی داده‌ها تا 40:1 و حذف داده‌های تکراری با سرعت بالا استفاده می‌کند و سربار ذخیره‌سازی را برای سیستم‌های CLM و SIEM کاهش می‌دهد.

کنسول جستجوی امنیت فناوری اطلاعات با جستجویی شبیه گوگل

یک ماژول تخصصی با رابط وب، جستجوی امنیت فناوری اطلاعات (ITSS)، می‌تواند به داده‌های رویداد در مخزن InTrust متصل شود و یک رابط کاربری ساده برای شکار تهدید ارائه دهد. این رابط کاربری آنقدر ساده شده است که مانند گوگل برای داده‌های ثبت رویداد کار می‌کند. ITSS از جدول زمانی برای نتایج پرس‌وجو استفاده می‌کند، می‌تواند فیلدهای رویداد را ادغام و گروه‌بندی کند و به طور مؤثر در شکار تهدید کمک کند.

InTrust رویدادها را غنی‌تر می‌کند Windows شناسه‌های امنیتی، نام فایل‌ها و شناسه‌های ورود امنیتی. InTrust همچنین رویدادها را به یک طرح ساده W6 (چه کسی، چه چیزی، کجا، چه زمانی، چه کسی و از کجا) نرمال‌سازی می‌کند تا داده‌ها از منابع مختلف (رویدادهای بومی) Windows، سیاهههای مربوط Linux یا syslog) را می‌توان در یک قالب واحد و در یک کنسول جستجوی واحد مشاهده کرد.

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

اسپری کردن رمز عبور.
کربراستینگ
فعالیت مشکوک PowerShell، مانند اجرای Mimikatz.
فرآیندهای مشکوک، مانند باج‌افزار LokerGoga.
رمزگذاری با استفاده از لاگ‌های CA4FS.
ورود با یک حساب کاربری ممتاز در ایستگاه‌های کاری.
حملات جستجوی فراگیر رمز عبور.
استفاده مشکوک از گروه‌ها و کاربران محلی.

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

فیلترهای از پیش تعریف شده برای جستجوی آسیب‌پذیری‌های احتمالی

نمونه‌ای از مجموعه‌ای از فیلترها برای جمع‌آوری داده‌های خام

مثالی از استفاده از عبارات منظم برای ایجاد پاسخ به یک رویداد

مثالی از قانون اسکن آسیب‌پذیری PowerShell

پایگاه دانش داخلی با توضیحات آسیب‌پذیری

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

من در این مقاله به یکپارچه‌سازی‌های آماده (out-of-the-box) نپرداختم. با این حال، بلافاصله پس از نصب، می‌توانید ارسال رویداد به Splunk، IBM QRadar، Microfocus Arcsight یا هر سیستم دیگری را از طریق یک وب‌هوک پیکربندی کنید. در زیر نمونه‌ای از رابط Kibana با رویدادهای InTrust آورده شده است. یکپارچه‌سازی با Elastic Stack نیز از قبل در دسترس است و اگر از نسخه رایگان Elastic استفاده می‌کنید، InTrust می‌تواند به عنوان ابزاری برای تشخیص تهدید، هشدار پیشگیرانه و اعلان‌ها استفاده شود.

امیدوارم این مقاله درک اولیه‌ای از این محصول به شما داده باشد. ما آماده‌ایم تا InTrust را برای آزمایش یا انجام یک پروژه آزمایشی به شما ارائه دهیم. می‌توانید درخواست خود را از طریق فرم انتقادات و پیشنهادات در وب سایت ما