پروژه جاری که با اسپلانک مدیریت میکنم رو سوئیچ کردم رو مبحث Detection as code . ترند بازار جهانی هست ، لذا گفتم منم اونو در پروژه های کشور پیاده کنم
#تجربه
براتون در دو بخش توضیح میدم
بخش اول :Detection as Code در Splunk: از مدیریت دستی تا مدیریت مهندسی‌شده
در بسیاری از SOCها، Ruleها، Correlation Searchها و Dashboardهای Splunk مستقیماً از طریق GUI ساخته و ویرایش می‌شوند. این روش هنوز رایج است، اما در محیط‌های بزرگ می‌تواند مشکلاتی مانند دشواری در ردگیری تغییرات، Rollback، کنترل کیفیت و انتقال منظم بین محیط‌های Dev، Test و Prod ایجاد کند.
در SOCهای بالغ‌تر، رویکرد Detection as Code به‌تدریج استفاده می‌شود. در این مدل، محتوای تشخیص مانند یک دارایی نرم‌افزاری مدیریت می‌شود. SPL Queryها، Metadata، Severity، Data Source، Mapping به MITRE ATT&CK و Response Action می‌توانند در Git Repository نگهداری شوند.
این کار باعث می‌شود تغییرات قابل بررسی، قابل بازگشت و قابل ممیزی باشند. همچنین تیم‌ها می‌توانند قبل از اعمال تغییرات در محیط عملیاتی، آن‌ها را Peer Review و Test کنند.
استفاده از Sigma نیز می‌تواند کمک کند Detectionها تا حدی مستقل‌تر از Vendor طراحی شوند، هرچند تبدیل Sigma به SPL همیشه نیازمند بررسی، تنظیم و اعتبارسنجی انسانی است.
اینو در سه هفته ی اخیر شروع کردم
اگر #تجربه ای بود به اشتراک میگذارم
✅در ادامه تجربه ام با اسپلانک در Detection as code بخش دوم تجربه رو مینویسم.
بخش دوم : Detection Testing و CI/CD در Splunk
در SOCهای پیشرفته، نوشتن Detection پایان کار نیست. هر Detection باید از نظر منطق، کیفیت داده، کارایی، نرخ خطای مثبت و قابلیت اجرا در محیط واقعی بررسی شود. به همین دلیل، برخی تیم‌ها از روش‌هایی الهام‌گرفته از مهندسی نرم‌افزار مانند Testing و CI/CD استفاده می‌کنند.
در این رویکرد، وقتی Detection جدیدی در Git ثبت می‌شود، می‌توان مراحلی مانند Lint Check، بررسی ساختار Rule، اعتبارسنجی Metadata، بررسی Mapping به ATT&CK و تست SPL را اجرا کرد. سپس Rule ابتدا در محیط Dev یا Test Splunk بررسی و پس از تأیید به Production منتقل می‌شود.
ابزارهایی مانند Atomic Red Team، Caldera و Prelude Operator نیز می‌توانند برای شبیه‌سازی رفتار مهاجم و ارزیابی عملکرد Detectionها استفاده شوند. البته این تست‌ها معادل کامل Unit Test نرم‌افزار نیستند، چون کیفیت Telemetry و رفتار واقعی مهاجم همیشه متغیر است.
بنابراین، Detection as Code یک جایگزین کامل برای تحلیلگر نیست؛ بلکه روشی برای استانداردسازی، کنترل کیفیت و بهبود مستمر عملیات SOC است.
با این حال در اجرا فعلا به مشکلاتی بر خوردم که کل پایپ لاین هنوز فول عملیاتی نشده
در هفته های آینده از #تجربه ام در Detection as code بیشتر مینویسم .
به امید بالغ شدن SOC های کشور
#تجربه
براتون در دو بخش توضیح میدم
بخش اول :Detection as Code در Splunk: از مدیریت دستی تا مدیریت مهندسی‌شده
در بسیاری از SOCها، Ruleها، Correlation Searchها و Dashboardهای Splunk مستقیماً از طریق GUI ساخته و ویرایش می‌شوند. این روش هنوز رایج است، اما در محیط‌های بزرگ می‌تواند مشکلاتی مانند دشواری در ردگیری تغییرات، Rollback، کنترل کیفیت و انتقال منظم بین محیط‌های Dev، Test و Prod ایجاد کند.
در SOCهای بالغ‌تر، رویکرد Detection as Code به‌تدریج استفاده می‌شود. در این مدل، محتوای تشخیص مانند یک دارایی نرم‌افزاری مدیریت می‌شود. SPL Queryها، Metadata، Severity، Data Source، Mapping به MITRE ATT&CK و Response Action می‌توانند در Git Repository نگهداری شوند.
این کار باعث می‌شود تغییرات قابل بررسی، قابل بازگشت و قابل ممیزی باشند. همچنین تیم‌ها می‌توانند قبل از اعمال تغییرات در محیط عملیاتی، آن‌ها را Peer Review و Test کنند.
استفاده از Sigma نیز می‌تواند کمک کند Detectionها تا حدی مستقل‌تر از Vendor طراحی شوند، هرچند تبدیل Sigma به SPL همیشه نیازمند بررسی، تنظیم و اعتبارسنجی انسانی است.
اینو در سه هفته ی اخیر شروع کردم
اگر #تجربه ای بود به اشتراک میگذارم
✅در ادامه تجربه ام با اسپلانک در Detection as code بخش دوم تجربه رو مینویسم.
بخش دوم : Detection Testing و CI/CD در Splunk
در SOCهای پیشرفته، نوشتن Detection پایان کار نیست. هر Detection باید از نظر منطق، کیفیت داده، کارایی، نرخ خطای مثبت و قابلیت اجرا در محیط واقعی بررسی شود. به همین دلیل، برخی تیم‌ها از روش‌هایی الهام‌گرفته از مهندسی نرم‌افزار مانند Testing و CI/CD استفاده می‌کنند.
در این رویکرد، وقتی Detection جدیدی در Git ثبت می‌شود، می‌توان مراحلی مانند Lint Check، بررسی ساختار Rule، اعتبارسنجی Metadata، بررسی Mapping به ATT&CK و تست SPL را اجرا کرد. سپس Rule ابتدا در محیط Dev یا Test Splunk بررسی و پس از تأیید به Production منتقل می‌شود.
ابزارهایی مانند Atomic Red Team، Caldera و Prelude Operator نیز می‌توانند برای شبیه‌سازی رفتار مهاجم و ارزیابی عملکرد Detectionها استفاده شوند. البته این تست‌ها معادل کامل Unit Test نرم‌افزار نیستند، چون کیفیت Telemetry و رفتار واقعی مهاجم همیشه متغیر است.
بنابراین، Detection as Code یک جایگزین کامل برای تحلیلگر نیست؛ بلکه روشی برای استانداردسازی، کنترل کیفیت و بهبود مستمر عملیات SOC است.
با این حال در اجرا فعلا به مشکلاتی بر خوردم که کل پایپ لاین هنوز فول عملیاتی نشده
در هفته های آینده از #تجربه ام در Detection as code بیشتر مینویسم .
به امید بالغ شدن SOC های کشور
Comments
Be the first to add a comment
Log in to comment