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

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

فرآیند پردازش لاگ در یک SIEM، دقیقاً همین هنر است. در این قسمت، ما روی مهم‌ترین و فنی‌ترین مرحله‌ی این آشپزی تمرکز می‌کنیم: مرحله‌ی «فیلتر». می‌خواهیم ببینیم پلتفرم‌های قدرتمندی مثل Splunk چگونه این «جادو» را انجام می‌دهند و داده‌های خام را به هوش امنیتی تبدیل می‌کنند. با ما همراه باشید.

مرحله‌ی فیلتر در یک پایپ‌لاین SIEM، فقط یک گام فنی نیست؛ بلکه مغز متفکر کل فرآیند است. اینجا جایی است که ما تصمیمات استراتژیک می‌گیریم و داده‌های بی‌ارزش را از داده‌های ارزشمند جدا می‌کنیم. این مرحله به طور کلی سه وظیفه‌ی اصلی و حیاتی بر عهده دارد:

درست است که این مرحله بیشترین زمان و انرژی را از تیم مهندسی SIEM می‌گیرد، اما به همان اندازه، بیشترین ارزش را به داده‌ها اضافه می‌کند و سنگ بنای تمام تحلیل‌های امنیتی دقیق و همبسته‌سازی‌های هوشمندانه است.

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

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

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

اینجاست که ابزار قدرتمند Regex یا Regular Expressions وارد میدان می‌شه. در هر پروژه‌ی بزرگی که کار کردم، تسلط بر Regex نقطه‌ی تمایز بین یک مهندس معمولی و یک معمار ارشد بوده. می‌شه بهش گفت «سس نینجای پارس کردن دستی». با Regex می‌توان تقریباً هر الگویی را از دل متن استخراج کرد، اما این قدرت بهایی هم دارد: عبارات Regex می‌توانند بسیار پیچیده، سخت‌خوان و از نظر محاسباتی پرهزینه باشند.

برای مثال، در Regex از کاراکترهای خاصی استفاده می‌کنیم:

اما نوشتن این عبارات پیچیده برای هر لاگ، کار عاقلانه‌ای نیست. به همین دلیل، پلتفرم‌هایی مانند Splunk از مفهومی به نام «الگوهای از پیش ساخته شده» (Grok Patterns) استفاده می‌کنند. به جای نوشتن یک Regex طولانی در هر بار، ما یک بار آن را در قالب یک الگو به نام IP تعریف می‌کنیم و از آن پس، به سادگی از این نام استفاده می‌کنیم.

برای اینکه درک کنید چرا این الگوها یک ضرورت هستند و نه فقط یک امکان رفاهی، اجازه بدید خودِ Regex واقعی برای استخراج یک آدرس IPv4 رو براتون توصیف کنم: یک رشته‌ی ترسناک و طولانی از پرانتز، علامت سوال، کروشه، اعداد و حروف که چندین خط طول می‌کشه. آیا واقعاً می‌خواهید همچین چیزی رو هر بار برای هر لاگ تایپ کنید و نگهداری‌اش کنید؟ قطعاً نه.

اینجاست که الگوها به کمک ما میان. فرض کنید لاگ ما این متنه: «The dog is brown». الگوی ما برای پارس کردنش به این شکل نوشته می‌شه: The %{WORD:animal} is %{WORD:color}. نتیجه‌اش دو فیلد جدیده: یکی به اسم animal با مقدار dog و یکی به اسم color با مقدار brown. این الگو روی لاگ‌های مشابه مثل «The cat is orange» هم به درستی کار می‌کنه.

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

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

اما خوشبختانه همیشه مجبور نیستیم با Regex دست و پنجه نرم کنیم. بسیاری از لاگ‌ها فرمت‌های ساختاریافته‌تری دارند که کار ما را ساده‌تر می‌کنند.

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

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

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

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

یکی از بزرگترین چالش‌ها، نرمال‌سازی زمان (Date/Time Normalization) است. لاگ‌ها از سیستم‌های مختلف با فرمت‌های زمانی بسیار متنوع و گاهی بدون مشخص بودن منطقه‌ی زمانی (Time Zone) به دست ما می‌رسند. برای تحلیل‌های دقیق و به خصوص برای همبسته‌سازی (Correlation) صحیح رخدادها در سیستم‌های مختلف، حیاتی است که تمام زمان‌ها به یک فرمت استاندارد و یکپارچه مانند UTC تبدیل شوند.

مفهوم مهم بعدی، حذف لاگ‌های بی‌ارزش (Dropping Logs) است. بسیاری از لاگ‌ها، مانند لاگ‌های سطح دیباگ (debug) یا برخی Event ID های بسیار پر سر و صدای ویندوز، هیچ ارزش تحلیلی ندارند و فقط حجم زیادی از فضای ذخیره‌سازی را مصرف می‌کنند. حذف این لاگ‌ها در همان ابتدای پایپ‌لاین (که در Splunk با ارسال آن‌ها به nullQueue انجام می‌شود)، تأثیر فوق‌العاده‌ای در کاهش هزینه‌ها و افزایش عملکرد کل سیستم دارد.

همچنین، باید فیلدهای غیرضروری را حذف کنیم (Removing Fields). نگهداری هر فیلد اضافی، فضا مصرف می‌کند و بر عملکرد جستجوها تأثیر منفی می‌گذارد. برای مثال، پس از اینکه پیام خام یک لاگ به طور کامل پارس شد و تمام فیلدهای مورد نیاز استخراج شدند، دیگر نیازی به نگهداری فیلد پیام خام اصلی نیست.

پس از پاک‌سازی، داده‌های ما تمیز و قابل استفاده هستند، اما هنوز «خاموش»اند. حالا نوبت به جذاب‌ترین بخش ماجرا می‌رسه: جایی که ما به این داده‌ها «هوش» و «زمینه» تزریق می‌کنیم تا بتونن داستان واقعی رو برای ما تعریف کنن. به این فرآیند می‌گیم غنی‌سازی.

غنی‌سازی لاگ را می‌توان مانند «افزودن ویتامین به غذا» در نظر گرفت. این مرحله اگرچه اجباری نیست، اما دقیقاً همان چیزی است که تفاوت بین یک سیستم SIEM معمولی و یک پلتفرم تحلیل امنیتی پیشرفته را رقم می‌زند. در این مرحله، ما داده‌های موجود را با اطلاعات بیرونی ترکیب می‌کنیم تا زمینه‌ی بیشتری برای تحلیل فراهم آوریم.

بیایید چند تکنیک کلیدی غنی‌سازی را با هم مرور کنیم:

همانطور که دیدیم، فرآیند پردازش لاگ یک خط مونتاژ سه‌مرحله‌ای و هوشمند است: ورودی (Input)، فیلتر و غنی‌سازی (Filter/Enrich)، و در نهایت خروجی (Output).

هر تحلیلگر یا معماری که در حال طراحی یک پایپ‌لاین پردازش لاگ است، باید این سوالات اساسی را از خود بپرسد:

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

از اینکه در این قسمت با ما همراه بودید سپاسگزاریم.