در قسمت اول مطلب گفتیم که جمعآوری داده و اعمال مجموعهی متغیری از روشهای شناسایی به انبوهی از دادهها نیازمند هوش تهدیدات، یک پشتهی تکنولوژی توانمند و تیمی ماهر پشت همهی این موارد است. در قلب مرکز عملیات امنیت (SOC) یک عملیات جمعآوری دادهی عظیم و پیچیده وجود دارد. از آنجا که تیمها به اطلاعات مربوط به رخدادها، هم در سطح شبکه و هم در سطح Host نیاز دارند، دسترسی به دادههای مناسب یکی از اولین چالشهایی است که هر تیمی باید با آن مواجه شود. سپس در خصوص انواع دادههایی که امکان جمعآوری دارند صحبت کردیم. در این قسمت به بررسی رخدادهای مختلفی که نیاز به جمعآوری دارند، صحبت خواهیم کرد.
انواع رخدادهایی که باید جمعآوری و نگهداری شوند
اجرای برنامه
- خط فرمان و Argumentها
- نام برنامه و مسیر فایل
- پردازش والد
- Hash
- Signature (امضای دیجیتال) – امضا شده یا بدون امضا، جزئیات امضا
- وضعیت لیست کنترل برنامه کاربردی (مجاز یا غیرمجاز)
اجرای اسکریپت
- ویندوز
- exe، wscript.exe، cmd.exe
- PowerShell – نامهای فایل اسکریپت، Logهای رونویسی، Logهای Block اسکریپت، Logهای ماژول
- macOS – osacript (AppleScript)
- لینوکس – sh، zsh، دستورات Bash و غیره
- زبانهای بین پلتفرمی مثل Python
Logهای احراز هویت
- کدام حسابهای کاربری با موفقیت لاگین میکنند یا نمیتوانند لاگین کنند؟
- چه نوعی از لاگین مورد استفاده قرار میگیرد؟ (لاگین Local، RDP، SSH و غیره)
- مکانیزمهای احراز هویت – Kerberos در مقابل NTLM، غیره
- در صورت ارتباط از راه دور، لاگین از کجا صورت گرفته؟
پیکربندی و مانیتورینگ پایهای
- اجرای سرویسها
- ایتمهای اجرای خودکار (Autorun)
- کارهای برنامهریزیشده
- اضافه شدن، حذف شدن، خواندن و اصلاح Registryها و فایلهای حساس
وضعیت آسیبپذیری
- سیستم عامل – نسخه و Patchهای نصبشده
- برنامههای کاربردی – چه چیزی و چه نسخهای نصب شده است؟
نکته: Logهای فایروال Host منبع فوقالعادهای از قابلیت دید هستند، اما معمولاً باید پیش از جمعآوری به خوبی فیلتر شوند و فقط پورتهایی که بهطور متداول برای حرکت جانبی یا Lateral Movement مورد استفاده قرار میگیرند و مبدأ و مقصدهایی که ترافیک در آنها غیرمنتظره است، انتخاب گردند.
- ترافیک ورودی/خروجی به پورتهایی که معمولاً مورد بهرهبرداری (Exploit) قرار میگیرند یا پورتهای غیرعادی (SMB، RDP، SSH، PowerShell Remoting، VNC، WMI، FTP و غیره)
- ترافیک ورودی/خروجی به/از مکانهای غیرمنتظره (گشتن به دنبال حرکت جانبی مثل ارتباط بین دستگاه کاربر به دستگاه کاربر)
- پورتهای Listening و برنامههایی که از آنها استفاده مینمایند.
- ترافیک خروجی/ورودی با فرایند (یک عامل متمایزکنندهی فیزیکی برای Logهای فایروال شبکه)
منابع Log ویندوز
منابع Log ویندوز در Windows Event Viewer به چند کانال تقسیم میشوند. بااینکه سیاست (Policy) ممیزی ویندوز شما تعیین میکند که کدام رخدادها آماری را در یکی از کانالها ایجاد کنند، تیم امنیتی مسئول است که انتخاب کند کدام کانالها و کدام رخدادها را داخل هر کانال جمعآوری نماید. توجه کنید که هرچند استانداردترین پیکربندی این است که با جمعآوری کانالهای امنیتی، سیستم و برنامهی کاربردی شروع کنید، این امر بههیچعنوان برای شناسایی بسیاری از حملات پیشرفته کافی نیست. برای دادن قدرت بیشتر به تیم خود جهت شناسایی حملات، کانالهای Log ویندوز که در ادامه معرفی میشوند (جایی که کاربرد داشته باشد) نیز باید برای جمعآوری Log مورد نظر قرار گیرد. توجه کنید که بسیاری از این کانالها نیازمند این هستند که یک سیاست فیلترینگ رخداد پرجزئیات توسط Agent جمعآوری Log براساس EventID یا حوزههای دیگر پیادهسازی شود تا فقط رخدادهای مربوط به امنیت جمعآوری گردند.
کانالهای Log ویندوز
- AppLocker
- DeviceGuard
- EMET
- PowerShell
- Security-Mitigations/Kernel-Mode (Windows Exploit Guard)
- Sysmon
- Windows Defender
- Windows Firewall با Advanced Security
- WMI-Activity
منابع Log در Linux یا Unix
Logهای سیستم مبتنی بر Unix معمولاً یا بهصورت فایلهای متنی ضبط میشوند که در ادامه نمایش داده شده است یا با استفاده از ژورنال systemd در ژورنال سیستم برای توزیعها ضبط میگردند. موارد زیر پیشنهاداتی برای شروع ساخت یک استراتژی Logging لینوکس هستند.
- /var/log/auth.log یا /var/log/secure
- /var/log/syslog یا /var/log/messages
- /var/log/audit/kern.log – Kernel logs
(بسیار طولانی با ارزش محدود)
- /var/log/audit/audit.log – Auditd logs
- /var/log/audit/ufw.log – Firewall logs
- /var/log/apache2 (or httpd) /access.log – Apache logs
- /var/log/httpd/mysqld.log – MySQL logs
Logging در Cloud
Logging و مانیتورینگ برای سیستمهای مبتنی بر Cloud را میتوان از چند شیوهی مختلف، بسته به نحوهی مدیریت سیستمها انجام داد. دو حوزهی اصلی تماشای مدیریت خود پلتفرم Cloud و مانیتورینگ سرورها، پلتفرمها یا برنامههای کاربردی است که در Cloud اجرا میگردند.
IaaS Logging
برای سیستمهایی که IaaS محسوب میشوند، Logging و مانیتورینگ با استفاده از مکانیزمهای یکسانی انجام میشود که اگر سیستم بهصورت On-Premise اجرا میکردید، از آنها استفاده میشد. ازآنجاییکه شما تقریباً در کنترل کامل سیستم هستید، Logging را میتوان مثل هر ماشین مجازی دیگری پیادهسازی نمود، معمولاً این پیادهسازی با استفاده از Agentهای Logی اتفاق میافتد که اطلاعاتی را درمورد سیستم، سیستم عامل و فعالیت برنامه کاربردی جمعآوری کرده و سپس آن را به یک SIEM متمرکز میفرستند.
Logهای Cloud Management Plane
یکی از نکات نگرانکننده برای تمام سرویسهای Cloud رابطهای کاربری مدیریتی هستند. هر سازمان دارای افرادی است که اجازه دارند برای مثال وارد کنسول Amazon AWS شوند و سرویسها و دادهها را بخوانند، اصلاح کنند، بسازند یا از بین ببرند. مهاجمی که به این عملکردهای مدیریتی دسترسی پیدا میکند میتواند بهسادگی و به شیوههای مختلف آسیب ایجاد نماید. در نتیجه مانیتورینگ سیستم Cloud همیشه باشد شامل ممیزی کسی که وارد پلتفرم مدیریتی میشوند و اعمالی که انجام میدهد باشد. منابع Logging مربوط به Cloud Management Plane شامل مواردی مثل Amazon CloudTrail و Azure Activity Logs هستند.
PaaS Logging و SaaS Logging
حتی بااینکه سازمان شما سیستم زیرین را در یک Platform as a Service یا Software as a Service کنترل نمیکند، نگرانیها درمورد امنیت آنها باید اولویت یکسانی با هر سیستم دیگری داشته باشد. Vendorهای PaaS و SaaS معمولاً جمعآوری Log را از طریق تماسهای API یا Logهای سرویس ممکن مینمایند که برای حوزهی بهخصوصی در پلتفرم Cloud آن Vendor نوشته میشوند (مثلاً برای یک S3 Bucket، Amazon CloudWatch، Azure Event Hub یا موارد مشابه). سپس این APIها و نقاط جمعآوری Log باید بهعنوان منابع Log که بهصورت خودکار Poll میشوند، در سامانه SIEM تنظیم گردند. Logهایی که جمعآوری میشوند باید شامل فعالیت برای سرویس و همچنین کاربرانی باشدکه با نرمافزار تعامل دارند و باید فعالیتهایی را ممیزی کنند که برای انجام آنها اقدام شده یا انجام شدهاند (تغییرات، لاگین/Logoff، اقدامات و غیره).
تفاوت بین SaaS و IaaS/PaaS این است که امنیت این سیستمها از کنترل شما خارج است و این Logها تنها گزینه برای مانیتورینگ میباشند و فقط شامل چیزی هستند که Vendor شما میخواهد با شما به اشتراک بگذارد. سازمانهایی که از راهکارهای SaaS استفاده میکنند باید بهدقت کاربردهای حملات روی این سیستمها و اهداف احتمالی مهاجمان را مدنظر قرار دهند و مشخص کنند که با توجه به قابلیت دیدی که از Vendor API برای آنها در دسترس است، این رخدادها چه ظاهری خواهند داشت. سپس باید قواعد تجزیهوتحلیل و هشداردهی در مورد این موارد کاربرد ایجاد گردند، تست شوند و بهطور مداوم اعتبارسنجی شوند تا از پوشش کامل اطمینان حاصل گردد.