طراحی Telemetry و Detection با Sysmon بدون تولید Noise

مفاهیم پایه و معماری Sysmon

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

رویدادهای اصلی Sysmon شامل شناسه‌های ۱ (ایجاد فرآیند)، ۲ (تغییر زمان ایجاد فایل)، ۳ (اتصال شبکه) و رویدادهای دیگری مانند بارگذاری درایورها و دسترسی خام به دیسک است. رویداد اتصال شبکه به‌صورت پیش‌فرض غیرفعال است و باید در پیکربندی فعال شود. این رویدادها در مسیر Applications and Services Logs/Microsoft/Windows/Sysmon/Operational ذخیره می‌شوند و زمان آن‌ها به‌صورت UTC ثبت می‌گردد.

نصب Sysmon با دستور sysmon64 -i انجام می‌شود که می‌تواند یک فایل پیکربندی را نیز دریافت کند. برای به‌روزرسانی پیکربندی در حال اجرا از دستور sysmon64 -c استفاده می‌شود. همچنین دستور sysmon64 -u برای حذف نصب به کار می‌رود. نکته مهم این است که Sysmon به‌تنهایی تحلیل رویدادها را انجام نمی‌دهد و صرفاً داده‌های خام را تولید می‌کند؛ بنابراین برای تشخیص ناهنجاری، باید این رویدادها به یک سیستم جمع‌آوری مرکزی مانند SIEM ارسال و تحلیل شوند.

• رویداد ۱: ایجاد فرآیند با جزئیات کامل خط فرمان و هش فایل
• رویداد ۲: تغییر زمان ایجاد فایل که می‌تواند نشانه‌ای از پاک‌سازی ردپا باشد
• رویداد ۳: اتصالات شبکه TCP/UDP با مشخصات فرآیند مبدأ و مقصد
• رویدادهای دیگر: بارگذاری درایورها، دسترسی خام به دیسک، و تغییرات در زمان ایجاد فایل

1. دانلود Sysmon از وب‌سایت رسمی مایکروسافت
2. اجرای دستور sysmon64 -i با فایل پیکربندی مناسب
3. تأیید نصب با بررسی سرویس در مدیریت خدمات
4. به‌روزرسانی پیکربندی با sysmon64 -c در صورت نیاز

sysmon64 -i config.xml
sysmon64 -c config.xml

منابع داده و تله‌متری مرتبط با MITRE ATT&CK

برای طراحی تشخیص مؤثر مبتنی بر Sysmon، نخستین گام، درک دقیق رابطه میان رویدادهای تولیدشده توسط این ابزار و منابع داده‌ای است که در چارچوب MITRE ATT&CK تعریف شده‌اند. این منابع داده، مانند Process، File، Network Traffic، Driver و Logon Session، نشان می‌دهند که هر تکنیک حمله‌ای چه نوع اطلاعاتی را برای شناسایی نیاز دارد. برای نمونه، تکنیک‌های مرتبط با اجرای فرمان یا اسکریپت‌نویسی معمولاً به داده‌های مربوط به فرایند (Process) وابسته‌اند، در حالی که تکنیک‌های جابه‌جایی جانبی ممکن است به داده‌های نشست ورود (Logon Session) نیاز داشته باشند.

توجه به این نکته ضروری است که در نسخه v18 از چارچوب ATT&CK، مفهوم «منابع داده» منسوخ اعلام شده و رویکرد جدیدی با عنوان «راهبردهای تشخیص هوشمندتر» جایگزین آن شده است. با این حال، این منابع داده همچنان به عنوان یک مرجع ارزشمند برای درک نوع تله‌متری مورد نیاز در طراحی تشخیص مورد استفاده قرار می‌گیرند. بنابراین، تحلیلگران دفاعی می‌توانند از این نگاشت‌ها به عنوان نقطه شروعی برای طراحی قواعد تشخیصی استفاده کنند، اما باید در نظر داشته باشند که این رویکردها در حال تکامل هستند و نباید صرفاً به آن‌ها اتکا کرد.

Sysmon به عنوان یک سرویس و درایور سیستم‌عامل ویندوز، رویدادهای دقیقی را در زمینه‌های مختلف تولید می‌کند که می‌توانند به منابع داده‌ای ATT&CK نگاشت شوند. برای مثال، رویدادهای مربوط به ایجاد فرایند (Event ID 1) اطلاعاتی مانند خط فرمان کامل، هش فایل اجرایی و شناسه فرایند را فراهم می‌کنند که به منبع داده «Process» مرتبط است. به همین ترتیب، رویدادهای مربوط به اتصالات شبکه (Event ID 3) اطلاعاتی درباره فرایند مبدأ، آدرس‌های IP و پورت‌ها ارائه می‌دهند که با منبع داده «Network Traffic» هماهنگ است. این نگاشت‌ها به تحلیلگران کمک می‌کند تا تشخیص‌های خود را بر اساس تکنیک‌های مشخص ATT&CK طراحی کنند.

برای طراحی تشخیص‌های کم‌نویز، پیشنهاد می‌شود که ابتدا فهرستی از تکنیک‌های پرخطر مورد نظر سازمان تهیه شود و سپس رویدادهای Sysmon مرتبط با هر تکنیک مشخص گردد. به عنوان مثال، برای شناسایی فعالیت‌های غیرعادی در بارگذاری درایورها (Driver)، می‌توان از رویداد 6 (بارگذاری درایور) استفاده کرد. اما باید توجه داشت که بسیاری از درایورهای معتبر نیز به صورت عادی بارگذاری می‌شوند؛ بنابراین لازم است قواعد تشخیصی با استفاده از لیست سفید (allowlist) برای امضاها و مسیرهای شناخته‌شده، نویز را کاهش داد. این توصیه بر اساس تجربه عملی است و باید با توجه به محیط خاص هر سازمان تنظیم شود.

• منابع داده‌ای مانند Process، File، Network Traffic، Driver و Logon Session در ATT&CK فهرست شده‌اند و برای مرجع قابل استفاده هستند.
• در نسخه v18 این منابع داده منسوخ شده‌اند، اما همچنان به عنوان راهنمای اولیه برای طراحی تشخیص مفید هستند.
• Sysmon رویدادهایی تولید می‌کند که می‌توانند به این منابع داده نگاشت شوند؛ برای مثال رویداد 1 به Process و رویداد 3 به Network Traffic مرتبط است.

1. تکنیک‌های پرخطر مورد نظر سازمان را از ATT&CK انتخاب کنید.
2. رویدادهای Sysmon مرتبط با هر تکنیک را مشخص کنید.
3. قواعد تشخیصی را با در نظر گرفتن منابع داده و زمینه‌های مرتبط طراحی کنید.
4. برای کاهش نویز، از لیست سفید و استثناهای شناخته‌شده استفاده کنید.

طراحی تله‌متری با پیکربندی بهینه Sysmon

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

پیکربندی بهینه نیازمند تعریف دقیق فیلترهای شامل و حذف برای هر رویداد است. برای مثال، رویداد ID 1 (ایجاد فرآیند) باید برای فرآیندهای حساس مانند powershell.exe، cmd.exe، wscript.exe و cscript.exe فعال باشد، اما اجرای منظم ابزارهای مدیریتی مانند msiexec.exe یا svchost.exe که در محیط عادی هستند، می‌تواند حذف شود. به همین ترتیب، رویداد ID 3 (اتصال شبکه) به‌صورت پیش‌فرض غیرفعال است و باید به‌طور صریح فعال شود؛ اما برای کاهش نویز، می‌توان اتصالات به آدرس‌های داخلی معتبر یا پورت‌های شناخته‌شده را فیلتر کرد. این کار باعث می‌شود تله‌متری بر روی فعالیت‌های پرخطر متمرکز شود.

علاوه بر فیلترها، انتخاب الگوریتم هش نیز اهمیت دارد. توصیه می‌شود از هش‌های SHA1 و MD5 به‌همراه IMPHASH استفاده شود تا امکان مقایسه با پایگاه‌های داده تهدید فراهم گردد. همچنین، فعال‌سازی رویداد ID 11 (ایجاد فایل) و ID 23 (حذف فایل) می‌تواند به شناسایی تلاش‌های دستکاری فایل‌های سیستمی کمک کند. در نهایت، باید از ثبت رویدادها از ابتدای فرآیند بوت (با استفاده از درایور بوت) اطمینان حاصل کرد تا هیچ فعالیت مخربی قبل از بارگذاری سرویس‌های معمولی از دید خارج نشود. این طراحی، تعادل مناسبی بین پوشش تهدید و کاهش نویز ایجاد می‌کند.

• فعال‌سازی رویداد ID 3 با فیلتر برای آدرس‌های داخلی و پورت‌های پرکاربرد
• استفاده از هش‌های SHA1، MD5 و IMPHASH برای شناسایی فایل‌های مخرب
• حذف رویدادهای تکراری از فرآیندهای سیستمی معتبر برای کاهش نویز
• فعال‌سازی رویدادهای مربوط به تغییر زمان ایجاد فایل (ID 2) و ایجاد فایل (ID 11)

1. نصب Sysmon با استفاده از دستور sysmon64 -i و سپس اعمال پیکربندی سفارشی
2. تعریف فیلترهای شامل برای فرآیندهای حساس و فیلترهای حذف برای فرآیندهای عادی
3. فعال‌سازی رویداد ID 3 با تنظیم Include برای اتصالات خروجی به آدرس‌های عمومی
4. تست پیکربندی در محیط آزمایشی برای اطمینان از عدم تولید نویز بیش از حد

sysmon64 -c config.xml

گردش کار جمع‌آوری و پردازش رویدادها

Sysmon به عنوان یک سرویس و درایور سیستم‌عامل ویندوز نصب می‌شود و به‌صورت بلادرنگ رویدادهای مرتبط با ایجاد فرآیند، اتصالات شبکه، تغییر زمان ایجاد فایل و بارگذاری درایورها را در لاگ رویداد ویندوز ثبت می‌کند. این رویدادها به‌طور پیش‌فرض در مسیر Applications and Services Logs/Microsoft/Windows/Sysmon/Operational ذخیره می‌شوند. برای بهره‌برداری مؤثر از این داده‌ها، لازم است آن‌ها به یک سیستم جمع‌آوری مرکزی مانند Windows Event Collection (WEC) یا عامل‌های SIEM ارسال شوند. این کار امکان تحلیل متمرکز، همبستگی رویدادها و تشخیص ناهنجاری‌ها را در سطح شبکه فراهم می‌کند.

در معماری جمع‌آوری، می‌توان از Windows Event Forwarding (WEF) برای ارسال رویدادها به یک سرور مرکزی استفاده کرد. این روش مبتنی بر پروتکل WinRM است و نیاز به نصب عامل اضافی ندارد. همچنین، عامل‌های SIEM مانند Splunk Universal Forwarder یا Elastic Agent می‌توانند رویدادها را به‌صورت مستقیم از لاگ رویداد ویندوز جمع‌آوری و به سرور SIEM ارسال کنند. انتخاب بین این روش‌ها به زیرساخت موجود، حجم رویدادها و نیازمندی‌های امنیتی بستگی دارد. در هر صورت، باید اطمینان حاصل شود که رویدادها به‌صورت بلادرنگ یا با تأخیر کم در دسترس تحلیلگران قرار می‌گیرند.

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

• رویدادهای Sysmon در لاگ اختصاصی Operational ذخیره می‌شوند.
• برای جمع‌آوری مرکزی، از Windows Event Collection یا عامل‌های SIEM استفاده می‌شود.
• فیلترینگ باید به‌گونه‌ای باشد که رویدادهای مهم حذف نشوند.

1. نصب Sysmon با استفاده از فایل پیکربندی مناسب.
2. پیکربندی Windows Event Forwarding یا نصب عامل SIEM.
3. تنظیم قوانین فیلترینگ در Sysmon و SIEM.
4. تست و اعتبارسنجی جریان رویدادها.

تحلیل و تریاژ رویدادها

تحلیل رویدادهای Sysmon نیازمند درک عمیق از ساختار داده‌ها و روابط بین رویدادها است. یکی از مهم‌ترین فیلدها برای همبستگی، ProcessGUID است که یک شناسه یکتای سراسری برای هر فرآیند در نظر گرفته می‌شود. این فیلد به تحلیلگر اجازه می‌دهد تا رویدادهای مرتبط با یک فرآیند خاص را حتی پس از بازیافت شناسه فرآیند (PID) توسط سیستم‌عامل، دنبال کند. برای مثال، اگر رویداد ایجاد فرآیند (Event ID 1) یک فرآیند را ثبت کند و سپس همان فرآیند یک اتصال شبکه (Event ID 3) برقرار کند، با استفاده از ProcessGUID می‌توان این دو رویداد را به هم مرتبط کرد و تصویر کاملی از رفتار فرآیند به دست آورد. این همبستگی پایه‌ای برای تحلیل زنجیره‌ای رویدادها و شناسایی الگوهای مشکوک مانند اجرای یک اسکریپت توسط یک سند Office است.

علاوه بر ProcessGUID، فیلد Session GUID نیز در رویدادهای Sysmon وجود دارد که امکان همبستگی رویدادهای مربوط به یک نشست ورود (Logon Session) واحد را فراهم می‌کند. این ویژگی به ویژه در سناریوهای بررسی فعالیت‌های یک کاربر خاص یا شناسایی حرکات جانبی (Lateral Movement) مفید است. برای مثال، اگر یک نشست ورود از راه دور (RDP) ایجاد شود و سپس در همان نشست، فرآیندهای غیرعادی مانند اجرای PowerShell یا ابزارهای مدیریتی اجرا شوند، تحلیلگر می‌تواند با فیلتر کردن بر اساس Session GUID، تمام فعالیت‌های مرتبط با آن نشست را به صورت متمرکز بررسی کند. این روش به کاهش نویز کمک می‌کند و تمرکز را بر روی رویدادهای مرتبط با یک زمینه امنیتی خاص نگه می‌دارد.

Sysmon اطلاعات دقیقی مانند خط فرمان کامل، هش فایل‌ها (با الگوریتم‌های SHA1، MD5، SHA256 و IMPHASH) و امضای درایورها و DLLها فراهم می‌کند. این اطلاعات برای تحلیل عمیق بسیار ارزشمند هستند. برای مثال، هش فایل می‌تواند با پایگاه‌های داده تهدیدات شناخته شده مقایسه شود یا برای جستجوی نمونه‌های مشابه در سایر سیستم‌ها استفاده شود. خط فرمان کامل نیز زمینه اجرای فرآیند را نشان می‌دهد و می‌تواند الگوهای مشکوکی مانند استفاده از ابزارهای زنده‌گوش (Living-off-the-land) یا اسکریپت‌های مبهم‌سازی شده را آشکار کند. با این حال، باید توجه داشت که Sysmon خود تحلیل رویدادها را انجام نمی‌دهد و صرفاً داده‌ها را جمع‌آوری می‌کند؛ بنابراین تحلیلگر باید با استفاده از ابزارهای SIEM یا موتورهای جستجوی لاگ، پرس‌وجوهای هدفمند ایجاد کند و بر اساس دانش خود از تکنیک‌های حمله، فرضیه‌های امنیتی را شکل دهد.

برای تریاژ مؤثر، پیشنهاد می‌شود ابتدا رویدادهای سطح بالا مانند ایجاد فرآیند (Event ID 1)، اتصال شبکه (Event ID 3) و تغییر زمان ایجاد فایل (Event ID 2) را با فیلترهای اولیه مانند حذف فرآیندهای شناخته شده و بی‌خطر (مثلاً فرآیندهای سیستمی) بررسی کنید. سپس با استفاده از ProcessGUID و Session GUID، رویدادهای مرتبط را به هم متصل کرده و زنجیره رویدادها را بازسازی کنید. در نهایت، بر اساس شواهد جمع‌آوری شده، تصمیم بگیرید که آیا رویدادها نیاز به بررسی بیشتر دارند یا خیر. این رویکرد مرحله‌ای به کاهش نویز و افزایش دقت تحلیل کمک می‌کند.

• از ProcessGUID برای پیگیری رویدادهای یک فرآیند در طول زمان استفاده کنید، حتی اگر PID تغییر کند.
• با استفاده از Session GUID، رویدادهای یک نشست ورود واحد را گروه‌بندی کنید تا فعالیت‌های مرتبط با یک کاربر یا نشست را به صورت متمرکز تحلیل کنید.
• خط فرمان کامل و هش فایل‌ها را به عنوان شواهد کلیدی در تحلیل در نظر بگیرید و آن‌ها را با منابع تهدید (مانند VirusTotal) مقایسه کنید.
• برای کاهش نویز، ابتدا رویدادهای شناخته شده و بی‌خطر را فیلتر کنید و سپس بر روی رویدادهای باقی‌مانده تمرکز کنید.

1. گام ۱: جمع‌آوری رویدادهای Sysmon از سیستم‌های هدف و انتقال آن‌ها به یک مخزن مرکزی (مانند SIEM).
2. گام ۲: ایجاد پرس‌وجوهای اولیه برای استخراج رویدادهای کلیدی (ایجاد فرآیند، اتصال شبکه، تغییر زمان ایجاد فایل) و حذف نویزهای شناخته شده.
3. گام ۳: همبستگی رویدادها با استفاده از ProcessGUID و Session GUID برای بازسازی زنجیره فعالیت‌ها.
4. گام ۴: تحلیل خط فرمان و هش فایل‌ها برای شناسایی شاخص‌های سازش (IOC) و مقایسه با منابع معتبر.
5. گام ۵: مستندسازی یافته‌ها و تصمیم‌گیری در مورد نیاز به بررسی عمیق‌تر یا اقدامات پاسخ.

مدیریت مثبت‌های کاذب و نویز

یکی از چالش‌های اصلی در طراحی Telemetry با Sysmon، مدیریت مثبت‌های کاذب و نویز است. رویدادهای Sysmon به‌ویژه رویدادهای مربوط به تغییر زمان ایجاد فایل (Event ID 2) و اتصالات شبکه (Event ID 3) می‌توانند به‌طور مکرر توسط فرآیندهای قانونی تولید شوند. برای مثال، بسیاری از نصب‌کننده‌های نرم‌افزار یا به‌روزرسانی‌های سیستم به‌طور عمدی زمان ایجاد فایل‌ها را تغییر می‌دهند تا با زمان نصب هماهنگ شوند. همچنین، اتصالات شبکه شامل ترافیک عادی مانند به‌روزرسانی‌های ویندوز، ارتباط با سرورهای DNS و یا نرم‌افزارهای همگام‌سازی ابری است. بدون فیلترهای دقیق، این رویدادها می‌توانند حجم عظیمی از داده‌های غیرمفید تولید کنند که تحلیلگران را از رویدادهای واقعاً مشکوک منحرف می‌کند.

برای کاهش نویز، ابتدا باید منابع رایج مثبت کاذب را شناسایی کرد. در مورد تغییر زمان ایجاد فایل، فرآیندهایی مانند Windows Explorer، سرویس‌های به‌روزرسانی ویندوز و ابزارهای پشتیبان‌گیری معمولاً این کار را انجام می‌دهند. در مورد اتصالات شبکه، فرآیندهای سیستمی مانند svchost.exe، lsass.exe و مرورگرهای وب به‌طور مداوم اتصالات برقرار می‌کنند. بنابراین، فیلترهای اولیه باید بر اساس نام فرآیند، مسیر فایل، آدرس IP مقصد و پورت طراحی شوند. به‌عنوان مثال، می‌توان اتصالات به آدرس‌های IP داخلی یا پورت‌های شناخته‌شده مانند 80 و 443 را برای فرآیندهای خاص نادیده گرفت، اما برای فرآیندهای غیرعادی که به این پورت‌ها متصل می‌شوند، هشدار صادر کرد.

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

• شناسایی فرآیندهای قانونی که تغییر زمان ایجاد فایل انجام می‌دهند (مانند Windows Explorer و سرویس‌های به‌روزرسانی).
• استفاده از فیلترهای exclude بر اساس نام فرآیند، مسیر فایل، آدرس IP و پورت برای رویدادهای شبکه.
• اجرای دوره‌ای بازبینی فیلترها برای تطبیق با تغییرات محیط.

1. نصب Sysmon با پیکربندی پیش‌فرض و جمع‌آوری رویدادها به مدت یک هفته.
2. تحلیل رویدادهای جمع‌آوری‌شده برای شناسایی الگوهای تکراری و غیرمفید.
3. افزودن فیلترهای exclude به پیکربندی Sysmon بر اساس تحلیل انجام‌شده.
4. تست پیکربندی جدید در محیط آزمایشی قبل از اعمال در محیط عملیاتی.

<Sysmon schemaversion="4.90">
  <EventFiltering>
    <ProcessCreate onmatch="exclude">
      <Image name="Windows Explorer">explorer.exe</Image>
    </ProcessCreate>
    <NetworkConnect onmatch="exclude">
      <Image name="svchost">svchost.exe</Image>
      <DestinationPort name="HTTP">80</DestinationPort>
      <DestinationPort name="HTTPS">443</DestinationPort>
    </NetworkConnect>
  </EventFiltering>
</Sysmon>

محدودیت‌های Sysmon و ملاحظات امنیتی

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

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

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

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

سنجش اثربخشی و عملیاتی‌سازی

ارزیابی عملکرد تشخیص مبتنی بر Sysmon نیازمند معیارهای کمّی و کیفی است که فراتر از شمارش رویدادها باشد. نرخ مثبت کاذب (False Positive Rate) یکی از مهم‌ترین شاخص‌هاست؛ زیرا هشدارهای غیرواقعی نه‌تنها حجم کاری تحلیلگران را افزایش می‌دهد، بلکه ممکن است منجر به بی‌اعتمادی به سیستم تشخیص و نادیده‌گرفتن هشدارهای واقعی شود. برای محاسبه این نرخ، لازم است تعداد رویدادهای علامت‌گذاری‌شده به‌عنوان مشکوک با تعداد رویدادهای تأییدشده توسط تحلیلگر مقایسه شود. همچنین پوشش رویدادها (Event Coverage) باید در برابر چارچوب‌هایی مانند تاکسونومی MITRE ATT&CK سنجیده شود تا اطمینان حاصل شود که داده‌های جمع‌آوری‌شده، رفتارهای مهم حمله را پوشش می‌دهند. زمان تشخیص (Time to Detect) نیز معیاری حیاتی است که فاصله بین وقوع رویداد و ثبت آن در سیستم نظارتی را نشان می‌دهد و باید در محدوده قابل قبول سازمانی حفظ شود.

برای عملیاتی‌سازی مؤثر، پیشنهاد می‌شود ابتدا پیکربندی Sysmon در محیط آزمایشی با ترافیک واقعی اما کنترل‌شده اجرا شود تا میزان نویز پایه مشخص گردد. سپس با استفاده از داده‌های جمع‌آوری‌شده، قوانین تشخیص بر اساس رفتارهای شناخته‌شده مانند اجرای فرمان‌های غیرمعمول یا اتصالات شبکه به آدرس‌های مشکوک تنظیم شود. هماهنگی نزدیک با تیم امنیت برای تعریف سناریوهای تهدید و اولویت‌بندی رویدادها ضروری است. توصیه می‌شود که پیکربندی Sysmon به‌صورت دوره‌ای (مثلاً ماهانه) بازبینی شود و نسخه‌های جدید ابزار و قواعد تشخیص با مستندات رسمی تطبیق داده شود. همچنین باید پوشش رویدادها (Event Coverage) نسبت به ماتریس MITRE ATT&CK سنجیده شود تا اطمینان حاصل گردد که داده‌های لازم برای شناسایی تکنیک‌های رایج مهاجمان جمع‌آوری می‌شود.

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

• پایش مستمر نرخ مثبت کاذب و منفی کاذب برای تنظیم دقیق قواعد تشخیص و کاهش نویز.
• استفاده از رویدادهای Sysmon مانند ایجاد فرایند (Event ID 1) و اتصال شبکه (Event ID 3) برای شناسایی ناهنجاری‌های رفتاری و همبستگی با داده‌های دیگر.
• هماهنگی منظم با تیم امنیت برای بازبینی قواعد و به‌روزرسانی پیکربندی بر اساس تهدیدهای نوظهور.

1. تعیین خط مبنا (Baseline) از رفتار عادی سیستم‌ها و کاربران برای تشخیص ناهنجاری‌ها.
2. طراحی داشبورد تحلیلی برای نظارت بر شاخص‌هایی مانند حجم رویدادها، توزیع زمانی و الگوهای تکراری.
3. برگزاری جلسات دوره‌ای بازبینی قواعد تشخیص با حضور تحلیلگران امنیت و مدیران سیستم.

Get-WinEvent -FilterHashtable @{LogName='Microsoft-Windows-Sysmon/Operational'; Id=1} | Group-Object -Property ProcessName | Sort-Object Count -Descending | Select-Object -First 20