مقوله Detection as Code؛ به‌کارگیری انضباط مهندسی نرم‌افزار در تشخیص تهدیدات
خلاصه مقاله
نویسنده در لینک زیر معتقد است بسیاری از تیم‌های امنیتی هنوز قوانین تشخیص (Detection Rules) را به‌صورت دستی در SIEM تغییر می‌دهند؛ بدون کنترل نسخه، بازبینی همتا، تست یا امکان بازگشت به نسخه قبلی. نتیجه این وضعیت، تولید هشدارهای فراوان، خطاهای منطقی و وابستگی به «دانش شفاهی» افراد است. Detection as Code راهکاری برای حل این مشکل است.
در این رویکرد، قوانین تشخیص همانند کد نرم‌افزار مدیریت می‌شوند. هر قانون در Git ذخیره میشود، دارای تاریخچه تغییرات است، پیش از انتشار بازبینی میشود و از طریق CI/CD به محیط عملیاتی منتقل می‌گردد. هر قانون باید دارای متادیتا مانند نویسنده، تاریخ بازبینی، تکنیک‌های ATT&CK، منبع داده و نرخ خطای مورد انتظار باشد. همچنین برای هر قانون باید تست مثبت و منفی تعریف شود تا مشخص شود چه رویدادهایی باید شناسایی شوند و چه رویدادهایی نباید هشدار تولید کنند.
مقاله نقش مهم Sigma را به‌عنوان زبان استاندارد و مستقل از فروشنده توضیح می‌دهد. Sigma امکان نوشتن یک قانون واحد و تبدیل آن به فرمت‌های مختلف مانند Splunk SPL، Sentinel KQL و Elastic EQL را فراهم می‌کند. در نتیجه، وابستگی به یک SIEM خاص کاهش می‌یابد و مهاجرت بین پلتفرم‌ها آسان‌تر میشود.
برای تشخیص مبتنی بر فایل و حافظه نیز YARA و YARA-X معرفی می‌شوند. YARA-X با کارایی بالاتر و قابلیت ادغام بهتر با CI/CD، امکان اعتبارسنجی خودکار قوانین را فراهم می‌کند.
نویسنده تأکید می‌کند که Detection as Code بدون تله‌متری مناسب و داده‌های باکیفیت موفق نخواهد شد. اگر لاگ‌ها ناقص یا فیلدها نادرست باشند، حتی بهترین فرآیندهای مهندسی نیز ارزشی ایجاد نمی‌کنند. همچنین هر قانون باید مالک مشخص و فرآیند رسیدگی تعریف‌شده داشته باشد.
به‌عنوان نقطه شروع، پیشنهاد میشود تنها پنج قانون مهم سازمان انتخاب شوند، در Git قرار گیرند، برای آنها تست تعریف شود و یک خط لوله CI ساده ایجاد گردد. سپس به‌تدریج پوشش ATT&CK، قوانین YARA، Shadow Mode و استقرار خودکار اضافه شوند. تجربه سازمان‌ها نشان داده است که این رویکرد می‌تواند حجم هشدارها را به‌طور محسوسی کاهش داده و مدیریت تشخیص را قابل ممیزی، قابل حمل و پایدار کند.
جمع‌بندی
پیام اصلی مقاله این است که Detection Engineering دیگر یک فعالیت عملیاتی ساده نیست؛ بلکه یک مسئله مهندسی نرم‌افزار است. همان‌طور که زیرساخت‌ها به Infrastructure as Code تبدیل شدند، قوانین تشخیص نیز باید به Detection as Code تبدیل شوند تا قابلیت کنترل، آزمون، ممیزی و توسعه مستمر داشته باشند
#MSSP #هامون
ثبت نام دوره CISSP از طریق بله 09902857290
https://andreafortuna.org/2026/06/17/detection-as-code/
خلاصه مقاله
نویسنده در لینک زیر معتقد است بسیاری از تیم‌های امنیتی هنوز قوانین تشخیص (Detection Rules) را به‌صورت دستی در SIEM تغییر می‌دهند؛ بدون کنترل نسخه، بازبینی همتا، تست یا امکان بازگشت به نسخه قبلی. نتیجه این وضعیت، تولید هشدارهای فراوان، خطاهای منطقی و وابستگی به «دانش شفاهی» افراد است. Detection as Code راهکاری برای حل این مشکل است.
در این رویکرد، قوانین تشخیص همانند کد نرم‌افزار مدیریت می‌شوند. هر قانون در Git ذخیره میشود، دارای تاریخچه تغییرات است، پیش از انتشار بازبینی میشود و از طریق CI/CD به محیط عملیاتی منتقل می‌گردد. هر قانون باید دارای متادیتا مانند نویسنده، تاریخ بازبینی، تکنیک‌های ATT&CK، منبع داده و نرخ خطای مورد انتظار باشد. همچنین برای هر قانون باید تست مثبت و منفی تعریف شود تا مشخص شود چه رویدادهایی باید شناسایی شوند و چه رویدادهایی نباید هشدار تولید کنند.
مقاله نقش مهم Sigma را به‌عنوان زبان استاندارد و مستقل از فروشنده توضیح می‌دهد. Sigma امکان نوشتن یک قانون واحد و تبدیل آن به فرمت‌های مختلف مانند Splunk SPL، Sentinel KQL و Elastic EQL را فراهم می‌کند. در نتیجه، وابستگی به یک SIEM خاص کاهش می‌یابد و مهاجرت بین پلتفرم‌ها آسان‌تر میشود.
برای تشخیص مبتنی بر فایل و حافظه نیز YARA و YARA-X معرفی می‌شوند. YARA-X با کارایی بالاتر و قابلیت ادغام بهتر با CI/CD، امکان اعتبارسنجی خودکار قوانین را فراهم می‌کند.
نویسنده تأکید می‌کند که Detection as Code بدون تله‌متری مناسب و داده‌های باکیفیت موفق نخواهد شد. اگر لاگ‌ها ناقص یا فیلدها نادرست باشند، حتی بهترین فرآیندهای مهندسی نیز ارزشی ایجاد نمی‌کنند. همچنین هر قانون باید مالک مشخص و فرآیند رسیدگی تعریف‌شده داشته باشد.
به‌عنوان نقطه شروع، پیشنهاد میشود تنها پنج قانون مهم سازمان انتخاب شوند، در Git قرار گیرند، برای آنها تست تعریف شود و یک خط لوله CI ساده ایجاد گردد. سپس به‌تدریج پوشش ATT&CK، قوانین YARA، Shadow Mode و استقرار خودکار اضافه شوند. تجربه سازمان‌ها نشان داده است که این رویکرد می‌تواند حجم هشدارها را به‌طور محسوسی کاهش داده و مدیریت تشخیص را قابل ممیزی، قابل حمل و پایدار کند.
جمع‌بندی
پیام اصلی مقاله این است که Detection Engineering دیگر یک فعالیت عملیاتی ساده نیست؛ بلکه یک مسئله مهندسی نرم‌افزار است. همان‌طور که زیرساخت‌ها به Infrastructure as Code تبدیل شدند، قوانین تشخیص نیز باید به Detection as Code تبدیل شوند تا قابلیت کنترل، آزمون، ممیزی و توسعه مستمر داشته باشند
#MSSP #هامون
ثبت نام دوره CISSP از طریق بله 09902857290
https://andreafortuna.org/2026/06/17/detection-as-code/
Andrea Fortuna
Applying software engineering discipline to threat detection
Detection as Code applies software engineering discipline to threat detection, replacing ad-hoc SIEM rule management with versioned, tested, and continuously deployed detection logic.
💯1
چالش این جمعه
موتور پیش بینی گوگل
قابل اجرا روی ماشین خودتون
https://github.com/google-research/timesfm
موتور پیش بینی گوگل
قابل اجرا روی ماشین خودتون
https://github.com/google-research/timesfm
GitHub
GitHub - google-research/timesfm: TimesFM (Time Series Foundation Model) is a pretrained time-series foundation model developed…
TimesFM (Time Series Foundation Model) is a pretrained time-series foundation model developed by Google Research for time-series forecasting. - google-research/timesfm
پروژه لاگ های شبیه واقع برای تدریس و آزمایشگاه و تست
برای آموزش های تیم آبی آکادمی روزبه
از دیوید بیانکو
https://blog.talosintelligence.com/introducing-evidenceforge-synthetic-security-logs-that-dont-look-as-fake/
گیت
https://github.com/Cisco-Talos/EvidenceForge
این لاگ‌ها به سازمان و مدرسین اجازه می‌دهند بدون اجرای حمله واقعی یا استفاده از داده‌های حساس، سناریوهای مختلف تهدید را شبیه‌سازی و اثربخشی قوانین تشخیص، SIEM، XDR و فرایندهای Threat Hunting را ارزیابی کند.
مزیت مهم دیگر، حفظ ارتباط منطقی بین رویدادها است؛ به‌گونه‌ای که آثار یک حمله در منابع مختلف تلمتری مانند Sysmon، لاگ‌های سیستم‌عامل، ترافیک شبکه و EDR به‌صورت هماهنگ بازسازی میشود. این ویژگی امکان سنجش دقیق پوشش تکنیک‌های مهاجمان بر اساس چارچوب‌هایی مانند ATT&CK را فراهم می‌کند. همچنین از این داده‌ها می‌توان برای آموزش تحلیلگران SOC، توسعه و تست Detection-as-Code و آموزش مدل‌های هوش مصنوعی امنیتی استفاده کرد. به همین دلیل، داده‌های مصنوعی در حال تبدیل شدن به یکی از ارکان مهم نسل جدید عملیات امنیت هستند.
برای آموزش های تیم آبی آکادمی روزبه
از دیوید بیانکو
https://blog.talosintelligence.com/introducing-evidenceforge-synthetic-security-logs-that-dont-look-as-fake/
گیت
https://github.com/Cisco-Talos/EvidenceForge
این لاگ‌ها به سازمان و مدرسین اجازه می‌دهند بدون اجرای حمله واقعی یا استفاده از داده‌های حساس، سناریوهای مختلف تهدید را شبیه‌سازی و اثربخشی قوانین تشخیص، SIEM، XDR و فرایندهای Threat Hunting را ارزیابی کند.
مزیت مهم دیگر، حفظ ارتباط منطقی بین رویدادها است؛ به‌گونه‌ای که آثار یک حمله در منابع مختلف تلمتری مانند Sysmon، لاگ‌های سیستم‌عامل، ترافیک شبکه و EDR به‌صورت هماهنگ بازسازی میشود. این ویژگی امکان سنجش دقیق پوشش تکنیک‌های مهاجمان بر اساس چارچوب‌هایی مانند ATT&CK را فراهم می‌کند. همچنین از این داده‌ها می‌توان برای آموزش تحلیلگران SOC، توسعه و تست Detection-as-Code و آموزش مدل‌های هوش مصنوعی امنیتی استفاده کرد. به همین دلیل، داده‌های مصنوعی در حال تبدیل شدن به یکی از ارکان مهم نسل جدید عملیات امنیت هستند.
Cisco Talos
Introducing EvidenceForge: Synthetic security logs that don’t look (as) fake
EvidenceForge generates high-quality, realistic, and consistent datasets across multiple log formats, enabling teams to effectively train personnel and validate detection models without the need for complex manual simulations.
👍3❤2💯1
خبر مهم و وظیفه ما
با توجه به انقضای بخشی از گواهی‌ها و کلیدهای قدیمی Secure Boot در سال ۲۰۲۶، سازمان باید یک برنامه هماهنگ برای شناسایی و به‌روزرسانی سیستم‌های تحت تأثیر اجرا کند.
تیم امنیت اطلاعات مسئول ارزیابی ریسک، تعیین الزامات و نظارت بر اجرای اقدامات است.
تیم‌های زیرساخت، ویندوز و لینوکس باید وضعیت به‌روزرسانی سیستم‌ها، Firmware/UEFI و کلیدهای Secure Boot را بررسی و اصلاح کنند.
تیم مدیریت دارایی باید فهرست کامل تجهیزات متاثر را تهیه و سیستم‌های خارج از پشتیبانی را شناسایی کند.
تیمSOC نیز باید پایش رویدادهای مرتبط با غیرفعال شدن Secure Boot، تغییرات Firmware و نشانه‌های احتمالی Bootkit را در دستور کار قرار دهد.
تیم مدیریت آسیب‌پذیری وضعیت اصلاح را رصد و موارد باقی‌مانده را گزارش کند.
همچنین مدیریت تغییرات و تیم تداوم کسب‌وکار باید برای آزمون، استقرار کنترل‌شده و برنامه‌های بازیابی آماده باشند.
هدف نهایی، حفظ زنجیره اعتماد Secure Boot، کاهش ریسک سوءاستفاده از ضعف‌های سطح بوت و جلوگیری از اختلال عملیاتی در سامانه‌های سازمان است.
https://arstechnica.com/security/2026/06/windows-and-linux-users-the-deadline-to-update-secure-boot-keys-is-near/
با توجه به انقضای بخشی از گواهی‌ها و کلیدهای قدیمی Secure Boot در سال ۲۰۲۶، سازمان باید یک برنامه هماهنگ برای شناسایی و به‌روزرسانی سیستم‌های تحت تأثیر اجرا کند.
تیم امنیت اطلاعات مسئول ارزیابی ریسک، تعیین الزامات و نظارت بر اجرای اقدامات است.
تیم‌های زیرساخت، ویندوز و لینوکس باید وضعیت به‌روزرسانی سیستم‌ها، Firmware/UEFI و کلیدهای Secure Boot را بررسی و اصلاح کنند.
تیم مدیریت دارایی باید فهرست کامل تجهیزات متاثر را تهیه و سیستم‌های خارج از پشتیبانی را شناسایی کند.
تیمSOC نیز باید پایش رویدادهای مرتبط با غیرفعال شدن Secure Boot، تغییرات Firmware و نشانه‌های احتمالی Bootkit را در دستور کار قرار دهد.
تیم مدیریت آسیب‌پذیری وضعیت اصلاح را رصد و موارد باقی‌مانده را گزارش کند.
همچنین مدیریت تغییرات و تیم تداوم کسب‌وکار باید برای آزمون، استقرار کنترل‌شده و برنامه‌های بازیابی آماده باشند.
هدف نهایی، حفظ زنجیره اعتماد Secure Boot، کاهش ریسک سوءاستفاده از ضعف‌های سطح بوت و جلوگیری از اختلال عملیاتی در سامانه‌های سازمان است.
https://arstechnica.com/security/2026/06/windows-and-linux-users-the-deadline-to-update-secure-boot-keys-is-near/
Ars Technica
Windows and Linux users: The deadline to update Secure Boot keys is near
What you need to know about the expiration of keys securing your machine's boot sequence.
❤2🙏1
#درس دوشنبه صبح در سازمان
در بسیاری از تیم‌های DFIR پیشرفته، Velociraptor برای شناسایی در سطح سازمان و KAPE برای جمع‌آوری عمیق شواهد از سیستم‌های منتخب استفاده میشود.
در بسیاری از تیم‌های DFIR پیشرفته، Velociraptor برای شناسایی در سطح سازمان و KAPE برای جمع‌آوری عمیق شواهد از سیستم‌های منتخب استفاده میشود.
👏4❤3💯1
مقوله Cascade Failure؛ تهدیدی که معماری ضعیف امنیت حوزه بانکی را آشکار می‌کند
از نگاه یک معمار امنیت و متخصص CISSP، بزرگ‌ترین خطر برای زیرساخت‌های بانکی الزاماً یک آسیب‌پذیری بحرانی نیست، بلکه Cascade Failure یا خرابی آبشاری است. در این حالت، اختلال در یک مؤلفه مانند سرویس هویت، ذخیره‌ساز مرکزی، لینک ارتباطی یا حتی سامانه EDR می‌تواند به دلیل وابستگی‌های معماری، به توقف زنجیره‌ای ده‌ها سرویس حیاتی منجر شود. نتیجه آن می‌تواند از کار افتادن اینترنت بانک، خودپردازها، سامانه‌های پرداخت، مراکز تماس و حتی ابزارهای مانیتورینگ باشد. معماری امنیتی باید با حذف نقاط تکین خرابی (Single Point of Failure)، جداسازی دامنه‌های عملیاتی، طراحی افزونگی (Redundancy)، محدودسازی Blast Radius و آزمون‌های منظم تاب‌آوری، از گسترش این اختلال جلوگیری کند. در واقع، امنیت معماری تنها به جلوگیری از نفوذ محدود نمی‌شود؛ بلکه تضمین می‌کند که حتی در صورت رخداد حمله یا خرابی، کل اکوسیستم بانکی دچار فروپاشی زنجیره‌ای نشود و خدمات حیاتی با کمترین اختلال ادامه یابد.
ثبت نام دوره CISSP از طریق بله 09902857290
#همیشه_بخوان
#آکادمی_روزبه
از نگاه یک معمار امنیت و متخصص CISSP، بزرگ‌ترین خطر برای زیرساخت‌های بانکی الزاماً یک آسیب‌پذیری بحرانی نیست، بلکه Cascade Failure یا خرابی آبشاری است. در این حالت، اختلال در یک مؤلفه مانند سرویس هویت، ذخیره‌ساز مرکزی، لینک ارتباطی یا حتی سامانه EDR می‌تواند به دلیل وابستگی‌های معماری، به توقف زنجیره‌ای ده‌ها سرویس حیاتی منجر شود. نتیجه آن می‌تواند از کار افتادن اینترنت بانک، خودپردازها، سامانه‌های پرداخت، مراکز تماس و حتی ابزارهای مانیتورینگ باشد. معماری امنیتی باید با حذف نقاط تکین خرابی (Single Point of Failure)، جداسازی دامنه‌های عملیاتی، طراحی افزونگی (Redundancy)، محدودسازی Blast Radius و آزمون‌های منظم تاب‌آوری، از گسترش این اختلال جلوگیری کند. در واقع، امنیت معماری تنها به جلوگیری از نفوذ محدود نمی‌شود؛ بلکه تضمین می‌کند که حتی در صورت رخداد حمله یا خرابی، کل اکوسیستم بانکی دچار فروپاشی زنجیره‌ای نشود و خدمات حیاتی با کمترین اختلال ادامه یابد.
ثبت نام دوره CISSP از طریق بله 09902857290
#همیشه_بخوان
#آکادمی_روزبه
👏3
#بحث فلسفی روز تعطیل
وقتی مایکروسافت برای EDR تصمیم می‌گیرد!
📝روزبه نوروزی
قابلیت PatchGuard برای محافظت از کرنل ویندوز طراحی شد، اما همزمان آزادی عمل بسیاری از ابزارهای امنیتی را نیز محدود کرد. این موضوع یک پرسش مهم ایجاد می‌کند: آیا باید معماری دفاع را فروشنده پلتفرم تعیین کند یا جامعه امنیت؟ حادثه CrowdStrike در سال ۲۰۲۴ نیز نشان داد که دسترسی سطح کرنل، علاوه بر قدرت دفاعی، می‌تواند به یک ریسک زیرساختی گسترده تبدیل شود. شاید PatchGuard بیش از آنکه یک قابلیت فنی باشد، آغاز یک بحث عمیق درباره آینده حکمرانی امنیت سایبری است.
مقوله PatchGuard امنیت integrity کرنل را بالا برد، اما روش مداخله‌ی سنتی EDR/AVها در کرنل را محدود کرد. این نکته‌ی مهم نیاز به دقت دارد: PatchGuard مانع حضور درایور EDR در سطح کرنل نشد - همه‌ی EDRهای بزرگ امروز (CrowdStrike, Defender, SentinelOne) همچنان درایور kernel-mode دارند و در Ring 0 می‌بینند. آنچه PatchGuard گرفت، امکان دستکاری مستقیم و غیررسمی ساختارهای داخلی کرنل بود (مثل SSDT hooking قدیمی). یعنی مسیر دفاع از "دیدن و دخالت بدون اجازه" به "دیدن از طریق API رسمی، ETW، callbacks و driver signing" منتقل شد ، نه اینکه دید عمیق به‌کلی گرفته شده باشد.
از نگاه مایکروسافت، حتی یک ابزار امنیتی با نیت خوب اگر کد یا ساختارهای حیاتی کرنل را patch کند، معماری مشابه رفتار rootkit دارد. هدف رسمی، حفظ integrity، reliability و resiliency ویندوز بوده.
اما نقد صنعت امنیت هم جدی است. وقتی vendor پلتفرم می‌گوید از این نقطه به بعد فقط از مسیرهایی که من تعریف کرده‌ام دخالت کن، عملاً قدرت تعریف معماری امنیت از بازار دفاعی به مالک سیستم‌عامل منتقل میشود ، حتی اگر دید نهایی (visibility) آسیب نبیند.
حادثه CrowdStrike در ۱۹ ژوئیه ۲۰۲۴ سمت دیگر ماجرا را نشان داد، و در واقع نکته را قوی‌تر می‌کند نه ضعیف‌تر: مشکل از کد جدید درایور نبود، بلکه از یک فایل پیکربندی (Channel File 291) بود که نحوه‌ی ارزیابی named pipe execution را در سطح کرنل کنترل می‌کرد . ریشه‌ی فنی، عدم تطابق بین ۲۱ ورودی که توسط Content Validator تایید می‌شد و ۲۰ ورودی که به Content Interpreter داده می‌شد بود ، که منجر به خواندن خارج از محدوده‌ی حافظه (out-of-bounds read) و کرش سیستم شد . نکته‌ی کلیدی: این فایل‌های Channel خودشان درایور کرنل نیستند، اما توسط کد سطح کرنل CrowdStrike پردازش می‌شوند. یعنی حتی یک فایل تنظیمات (نه کد جدید) توانست با دسترسی کرنل کل ویندوز را از کار بیندازد ، این argument برای ریسک "دسترسی عمیق" قوی‌تر از نسخه‌ی قبلی است.
جالب اینجاست که خود CrowdStrike در RCA رسمی‌اش متعهد شد با مایکروسافت روی دسترسی امن‌تر و مطمئن‌تر به کرنل ویندوز کار کند و اشاره کرد با معرفی نسخه‌های جدید ویندوز که امکان انجام بیشتر این توابع امنیتی در user space را فراهم می‌کنند، عامل خود را برای استفاده از این قابلیت به‌روزرسانی می‌کند . این دقیقاً همان جهتی است که بحث فلسفی من درباره‌اش است: صنعت خودش هم دارد به سمت کاهش وابستگی به دسترسی کرنل حرکت می‌کند، نه فقط به فشار مایکروسافت.
پس مسئله این نیست که PatchGuard خوب است یا بد. مسئله این است که امنیت کرنل سه خطر همزمان دارد: اگر مسیر تغییر کرنل باز باشد، EDR قدرت مداخله‌ی بیشتری دارد ولی malware و driver مخرب هم همان میدان را می‌گیرند؛ اگر بسته باشد، integrity و پایداری بهتر میشود ولی vendor lock-in و تمرکز قدرت در دست مالک پلتفرم بالا می‌رود؛ و اگر امنیت کاملاً به API رسمی مایکروسافت وابسته شود، اکوسیستم دفاعی ممکن است خلاقیت و استقلال کمتری داشته باشد.
از نگاه معماری امنیت، بهترین پاسخ یک مدل میانه است: کرنل نباید محل مداخله‌ی بی‌قاعده‌ی فروشندگان امنیتی باشد، اما مایکروسافت هم نباید تنها مرجع انحصاری تعریف visibility و control باشد. باید APIهای رسمی، غنی، قابل audit، با SLA شفاف، telemetry سطح پایین، staged rollout اجباری برای content update ها (نه فقط کد)، و امکان رقابت برابر برای vendorها وجود داشته باشد.
جمع‌بندی فلسفی: PatchGuard دفاع را ضعیف نکرد؛ مسیر تغییر دادن کرنل را محدود کرد، نه مسیر دیدن آن. اما حادثه‌ی CrowdStrike نشان داد حتی دیدن و پردازش در سطح کرنل - بدون هیچ patch غیررسمی - به‌خودی‌خود ریسک سیستمیک ایجاد می‌کند. وقتی امنیت از اکوسیستم دفاعی متنوع به حاکمیت متمرکز چند vendor با دسترسی کرنل تبدیل میشود، این همان single point of failure خطرناک است ، صرف‌نظر از اینکه آن دسترسی از طریق patch غیررسمی باشد یا API کاملاً رسمی و مجاز.
وقتی مایکروسافت برای EDR تصمیم می‌گیرد!
📝روزبه نوروزی
قابلیت PatchGuard برای محافظت از کرنل ویندوز طراحی شد، اما همزمان آزادی عمل بسیاری از ابزارهای امنیتی را نیز محدود کرد. این موضوع یک پرسش مهم ایجاد می‌کند: آیا باید معماری دفاع را فروشنده پلتفرم تعیین کند یا جامعه امنیت؟ حادثه CrowdStrike در سال ۲۰۲۴ نیز نشان داد که دسترسی سطح کرنل، علاوه بر قدرت دفاعی، می‌تواند به یک ریسک زیرساختی گسترده تبدیل شود. شاید PatchGuard بیش از آنکه یک قابلیت فنی باشد، آغاز یک بحث عمیق درباره آینده حکمرانی امنیت سایبری است.
مقوله PatchGuard امنیت integrity کرنل را بالا برد، اما روش مداخله‌ی سنتی EDR/AVها در کرنل را محدود کرد. این نکته‌ی مهم نیاز به دقت دارد: PatchGuard مانع حضور درایور EDR در سطح کرنل نشد - همه‌ی EDRهای بزرگ امروز (CrowdStrike, Defender, SentinelOne) همچنان درایور kernel-mode دارند و در Ring 0 می‌بینند. آنچه PatchGuard گرفت، امکان دستکاری مستقیم و غیررسمی ساختارهای داخلی کرنل بود (مثل SSDT hooking قدیمی). یعنی مسیر دفاع از "دیدن و دخالت بدون اجازه" به "دیدن از طریق API رسمی، ETW، callbacks و driver signing" منتقل شد ، نه اینکه دید عمیق به‌کلی گرفته شده باشد.
از نگاه مایکروسافت، حتی یک ابزار امنیتی با نیت خوب اگر کد یا ساختارهای حیاتی کرنل را patch کند، معماری مشابه رفتار rootkit دارد. هدف رسمی، حفظ integrity، reliability و resiliency ویندوز بوده.
اما نقد صنعت امنیت هم جدی است. وقتی vendor پلتفرم می‌گوید از این نقطه به بعد فقط از مسیرهایی که من تعریف کرده‌ام دخالت کن، عملاً قدرت تعریف معماری امنیت از بازار دفاعی به مالک سیستم‌عامل منتقل میشود ، حتی اگر دید نهایی (visibility) آسیب نبیند.
حادثه CrowdStrike در ۱۹ ژوئیه ۲۰۲۴ سمت دیگر ماجرا را نشان داد، و در واقع نکته را قوی‌تر می‌کند نه ضعیف‌تر: مشکل از کد جدید درایور نبود، بلکه از یک فایل پیکربندی (Channel File 291) بود که نحوه‌ی ارزیابی named pipe execution را در سطح کرنل کنترل می‌کرد . ریشه‌ی فنی، عدم تطابق بین ۲۱ ورودی که توسط Content Validator تایید می‌شد و ۲۰ ورودی که به Content Interpreter داده می‌شد بود ، که منجر به خواندن خارج از محدوده‌ی حافظه (out-of-bounds read) و کرش سیستم شد . نکته‌ی کلیدی: این فایل‌های Channel خودشان درایور کرنل نیستند، اما توسط کد سطح کرنل CrowdStrike پردازش می‌شوند. یعنی حتی یک فایل تنظیمات (نه کد جدید) توانست با دسترسی کرنل کل ویندوز را از کار بیندازد ، این argument برای ریسک "دسترسی عمیق" قوی‌تر از نسخه‌ی قبلی است.
جالب اینجاست که خود CrowdStrike در RCA رسمی‌اش متعهد شد با مایکروسافت روی دسترسی امن‌تر و مطمئن‌تر به کرنل ویندوز کار کند و اشاره کرد با معرفی نسخه‌های جدید ویندوز که امکان انجام بیشتر این توابع امنیتی در user space را فراهم می‌کنند، عامل خود را برای استفاده از این قابلیت به‌روزرسانی می‌کند . این دقیقاً همان جهتی است که بحث فلسفی من درباره‌اش است: صنعت خودش هم دارد به سمت کاهش وابستگی به دسترسی کرنل حرکت می‌کند، نه فقط به فشار مایکروسافت.
پس مسئله این نیست که PatchGuard خوب است یا بد. مسئله این است که امنیت کرنل سه خطر همزمان دارد: اگر مسیر تغییر کرنل باز باشد، EDR قدرت مداخله‌ی بیشتری دارد ولی malware و driver مخرب هم همان میدان را می‌گیرند؛ اگر بسته باشد، integrity و پایداری بهتر میشود ولی vendor lock-in و تمرکز قدرت در دست مالک پلتفرم بالا می‌رود؛ و اگر امنیت کاملاً به API رسمی مایکروسافت وابسته شود، اکوسیستم دفاعی ممکن است خلاقیت و استقلال کمتری داشته باشد.
از نگاه معماری امنیت، بهترین پاسخ یک مدل میانه است: کرنل نباید محل مداخله‌ی بی‌قاعده‌ی فروشندگان امنیتی باشد، اما مایکروسافت هم نباید تنها مرجع انحصاری تعریف visibility و control باشد. باید APIهای رسمی، غنی، قابل audit، با SLA شفاف، telemetry سطح پایین، staged rollout اجباری برای content update ها (نه فقط کد)، و امکان رقابت برابر برای vendorها وجود داشته باشد.
جمع‌بندی فلسفی: PatchGuard دفاع را ضعیف نکرد؛ مسیر تغییر دادن کرنل را محدود کرد، نه مسیر دیدن آن. اما حادثه‌ی CrowdStrike نشان داد حتی دیدن و پردازش در سطح کرنل - بدون هیچ patch غیررسمی - به‌خودی‌خود ریسک سیستمیک ایجاد می‌کند. وقتی امنیت از اکوسیستم دفاعی متنوع به حاکمیت متمرکز چند vendor با دسترسی کرنل تبدیل میشود، این همان single point of failure خطرناک است ، صرف‌نظر از اینکه آن دسترسی از طریق patch غیررسمی باشد یا API کاملاً رسمی و مجاز.
❤2👍2💯1
دیوید بیانکو (David Bianco)، خالق مدل معروف Pyramid of Pain، یک سرویس رایگان به نام CFPlease.io راه‌اندازی کرده است.
ایده اصلی چیست؟
یکی از مشکلات جامعه امنیت سایبری این است که اطلاعیه‌های Call for Papers (CFP) کنفرانس‌ها، ورکشاپ‌ها و رویدادها در سایت‌ها و شبکه‌های مختلف پراکنده هستند و پیدا کردن آنها زمان‌بر است.
دیوید بیانکو برای حل این مشکل، CFPlease.io را توسعه داده است.
این ابزار چه کار می‌کند؟
به‌صورت خودکار اینترنت را Crawl می‌کند.وCFPهای جدید کنفرانس‌های امنیت سایبری را جمع‌آوری می‌کند.
امکان جستجو و فیلتر بر اساس:
موضوع (Threat Hunting، DFIR، Cloud Security، AI Security و ...)
نوع رویداد (حضوری یا آنلاین)
موقعیت جغرافیایی
زمان برگزاری را فراهم می‌کند.
چرا این ابزار مهم است؟
برای پژوهشگران، مدرسان، مشاوران و متخصصان امنیت، پیدا کردن محل مناسب برای ارائه مقاله یا سخنرانی معمولاً نیازمند بررسی ده‌ها سایت مختلف است. CFPlease این اطلاعات را در یک نقطه متمرکز می‌کند و زمان جستجو را به شدت کاهش می‌دهد.
کاربرد برای متخصصان ایرانی
اگر مدرس CISSP، پژوهشگر، Threat Hunter یا معمار امنیت باشید، این ابزار می‌تواند به شما کمک کند:
کنفرانس‌های بین‌المللی مرتبط با حوزه تخصصی خود را پیدا کنید.
از مهلت ارسال مقاله (Submission Deadline) جا نمانید.
فرصت‌های سخنرانی و انتشار پژوهش را شناسایی کنید.
روندهای روز امنیت سایبری را از طریق موضوعات CFPها دنبال کنید.
در واقع، CFPlease بیشتر یک موتور جستجوی هوشمند برای رویدادها و Call for Papers امنیت سایبری است که با هدف خدمت رایگان به جامعه امنیت توسط دیوید بیانکو توسعه داده شده است.
https://cfplease.io/cfps
ایده اصلی چیست؟
یکی از مشکلات جامعه امنیت سایبری این است که اطلاعیه‌های Call for Papers (CFP) کنفرانس‌ها، ورکشاپ‌ها و رویدادها در سایت‌ها و شبکه‌های مختلف پراکنده هستند و پیدا کردن آنها زمان‌بر است.
دیوید بیانکو برای حل این مشکل، CFPlease.io را توسعه داده است.
این ابزار چه کار می‌کند؟
به‌صورت خودکار اینترنت را Crawl می‌کند.وCFPهای جدید کنفرانس‌های امنیت سایبری را جمع‌آوری می‌کند.
امکان جستجو و فیلتر بر اساس:
موضوع (Threat Hunting، DFIR، Cloud Security، AI Security و ...)
نوع رویداد (حضوری یا آنلاین)
موقعیت جغرافیایی
زمان برگزاری را فراهم می‌کند.
چرا این ابزار مهم است؟
برای پژوهشگران، مدرسان، مشاوران و متخصصان امنیت، پیدا کردن محل مناسب برای ارائه مقاله یا سخنرانی معمولاً نیازمند بررسی ده‌ها سایت مختلف است. CFPlease این اطلاعات را در یک نقطه متمرکز می‌کند و زمان جستجو را به شدت کاهش می‌دهد.
کاربرد برای متخصصان ایرانی
اگر مدرس CISSP، پژوهشگر، Threat Hunter یا معمار امنیت باشید، این ابزار می‌تواند به شما کمک کند:
کنفرانس‌های بین‌المللی مرتبط با حوزه تخصصی خود را پیدا کنید.
از مهلت ارسال مقاله (Submission Deadline) جا نمانید.
فرصت‌های سخنرانی و انتشار پژوهش را شناسایی کنید.
روندهای روز امنیت سایبری را از طریق موضوعات CFPها دنبال کنید.
در واقع، CFPlease بیشتر یک موتور جستجوی هوشمند برای رویدادها و Call for Papers امنیت سایبری است که با هدف خدمت رایگان به جامعه امنیت توسط دیوید بیانکو توسعه داده شده است.
https://cfplease.io/cfps
❤4🙏3👌1
پیشنهاد برای افتا و زیرساخت‌های حیاتی
همان‌گونه که ISO 27001 مبنای امنیت اطلاعات و CCM مرجع امنیت ابر محسوب میشود، AI Controls Matrix می‌تواند به عنوان مرجع ملی برای ارزیابی امنیت سامانه‌های مبتنی بر هوش مصنوعی مورد استفاده قرار گیرد. سازمان‌هایی که قصد توسعه Agentها، دستیارهای هوشمند یا سامانه‌های مبتنی بر LLM را دارند، بهتر است کنترل‌های این چارچوب را در فرآیند طراحی، توسعه، بهره‌برداری و ممیزی خود بگنجانند. این رویکرد باعث میشود امنیت AI از یک فعالیت واکنشی به بخشی از معماری و حکمرانی سازمان تبدیل شود
https://cloudsecurityalliance.org/artifacts/ai-controls-matrix-v1-1
همان‌گونه که ISO 27001 مبنای امنیت اطلاعات و CCM مرجع امنیت ابر محسوب میشود، AI Controls Matrix می‌تواند به عنوان مرجع ملی برای ارزیابی امنیت سامانه‌های مبتنی بر هوش مصنوعی مورد استفاده قرار گیرد. سازمان‌هایی که قصد توسعه Agentها، دستیارهای هوشمند یا سامانه‌های مبتنی بر LLM را دارند، بهتر است کنترل‌های این چارچوب را در فرآیند طراحی، توسعه، بهره‌برداری و ممیزی خود بگنجانند. این رویکرد باعث میشود امنیت AI از یک فعالیت واکنشی به بخشی از معماری و حکمرانی سازمان تبدیل شود
https://cloudsecurityalliance.org/artifacts/ai-controls-matrix-v1-1
cloudsecurityalliance.org
AI Controls Matrix | Framework for Trustworthy AI | CSA
The AI Controls Matrix is a vendor-neutral framework for secure, responsible AI systems in the cloud. Based on CCM and aligned with ISO 42001, NIST AI, & more.
👏3
مقاله زیر : RAID Forensics؛
چرا بازسازی عجولانه می‌تواند شواهد را نابود کند؟
در بسیاری از پرونده‌های فارنزیک دیجیتال، کارشناسان با سامانه‌های ذخیره‌سازی RAID مواجه می‌شوند که هیچ مستنداتی از نوع پیکربندی، ترتیب دیسک‌ها یا پارامترهای فنی آنها در دسترس نیست. مقاله تأکید می‌کند که در چنین شرایطی، بزرگ‌ترین اشتباه روشن کردن مجدد سیستم یا تلاش برای بازسازی سریع آرایه است، زیرا این اقدام ممکن است متادیتا را تغییر داده، اطلاعات را بازنویسی کند و در نهایت ارزش حقوقی شواهد را از بین ببرد.
رویکرد صحیح از مستندسازی دقیق آغاز میشود. پیش از هر اقدامی باید از وضعیت فیزیکی دیسک‌ها، شماره اسلات‌ها، کنترلر، کابل‌ها و اتصالات عکس‌برداری و مستندات کامل تهیه شود. سپس از هر دیسک به‌صورت مستقل یک تصویر (Forensic Image) تهیه و مقادیر Hash ثبت میشود تا یکپارچگی شواهد و زنجیره نگهداری آنها حفظ شود.
مرحله بعدی، تحلیل ساختار RAID است. تحلیلگر باید با بررسی داده‌های خام، متادیتا، ساختار فایل‌سیستم و الگوهای ذخیره‌سازی، پارامترهایی مانند نوع RAID، ترتیب دیسک‌ها، اندازه Stripe، Offset و نحوه محاسبه Parity را شناسایی کند. این فرآیند باید با استفاده از ابزارهای تخصصی و بدون ایجاد هیچ تغییری روی داده‌های اصلی انجام شود.
پیام اصلی مقاله این است که موفقیت در RAID Forensics بیش از آنکه به ابزار وابسته باشد، به رعایت یک روش‌شناسی دقیق و اصول علمی بستگی دارد. یک تصمیم اشتباه در لحظات اولیه می‌تواند برای همیشه امکان بازیابی داده‌ها را از بین ببرد، در حالی که مستندسازی صحیح، تهیه Image از هر دیسک و بازسازی مرحله‌به‌مرحله آرایه، حتی در پیکربندی‌های ناشناخته نیز امکان استخراج شواهد معتبر و قابل استناد در تحقیقات DFIR را فراهم می‌کند.
این رویکرد، تفاوت میان یک بازیابی موفق و از دست رفتن همیشگی شواهد دیجیتال را رقم می‌زند.
https://www.forensicfocus.com/articles/raid-forensics-handling-unknown-configurations-in-dfir-investigations/
چرا بازسازی عجولانه می‌تواند شواهد را نابود کند؟
در بسیاری از پرونده‌های فارنزیک دیجیتال، کارشناسان با سامانه‌های ذخیره‌سازی RAID مواجه می‌شوند که هیچ مستنداتی از نوع پیکربندی، ترتیب دیسک‌ها یا پارامترهای فنی آنها در دسترس نیست. مقاله تأکید می‌کند که در چنین شرایطی، بزرگ‌ترین اشتباه روشن کردن مجدد سیستم یا تلاش برای بازسازی سریع آرایه است، زیرا این اقدام ممکن است متادیتا را تغییر داده، اطلاعات را بازنویسی کند و در نهایت ارزش حقوقی شواهد را از بین ببرد.
رویکرد صحیح از مستندسازی دقیق آغاز میشود. پیش از هر اقدامی باید از وضعیت فیزیکی دیسک‌ها، شماره اسلات‌ها، کنترلر، کابل‌ها و اتصالات عکس‌برداری و مستندات کامل تهیه شود. سپس از هر دیسک به‌صورت مستقل یک تصویر (Forensic Image) تهیه و مقادیر Hash ثبت میشود تا یکپارچگی شواهد و زنجیره نگهداری آنها حفظ شود.
مرحله بعدی، تحلیل ساختار RAID است. تحلیلگر باید با بررسی داده‌های خام، متادیتا، ساختار فایل‌سیستم و الگوهای ذخیره‌سازی، پارامترهایی مانند نوع RAID، ترتیب دیسک‌ها، اندازه Stripe، Offset و نحوه محاسبه Parity را شناسایی کند. این فرآیند باید با استفاده از ابزارهای تخصصی و بدون ایجاد هیچ تغییری روی داده‌های اصلی انجام شود.
پیام اصلی مقاله این است که موفقیت در RAID Forensics بیش از آنکه به ابزار وابسته باشد، به رعایت یک روش‌شناسی دقیق و اصول علمی بستگی دارد. یک تصمیم اشتباه در لحظات اولیه می‌تواند برای همیشه امکان بازیابی داده‌ها را از بین ببرد، در حالی که مستندسازی صحیح، تهیه Image از هر دیسک و بازسازی مرحله‌به‌مرحله آرایه، حتی در پیکربندی‌های ناشناخته نیز امکان استخراج شواهد معتبر و قابل استناد در تحقیقات DFIR را فراهم می‌کند.
این رویکرد، تفاوت میان یک بازیابی موفق و از دست رفتن همیشگی شواهد دیجیتال را رقم می‌زند.
https://www.forensicfocus.com/articles/raid-forensics-handling-unknown-configurations-in-dfir-investigations/
Forensic Focus
RAID Forensics: Handling Unknown Configurations In DFIR Investigations - Forensic Focus
Unlabelled RAID drives, no documentation, and a ticking evidence integrity clock: here’s how investigators can avoid the most common RAID forensics mistakes before they compromise a case.
🙏2
فورتی سند باکس را وصله کنید !
https://linuxsecurity.com/news/security-vulnerabilities/malware-analysis-sandbox-security-risks
https://linuxsecurity.com/news/security-vulnerabilities/malware-analysis-sandbox-security-risks
Linux Security
Fortinet FortiSandbox Critical Command Execution Risk Exploit 2026-39813
Fortinet has confirmed active exploitation of three FortiSandbox vulnerabilities. One allows attackers to bypass login controls, while the other two enable command execution directly on the appliance. Combined, they create a path from unauthenticated access…
👍3❤2
آنچه که اکسپلویت آمده ولی وصله ندارد
بررسی کنیم چطور در سازمان در برابر این آسیب پذیری که در اثر اختلاف یک هکر و مایکروسافت زود منتشر شده و بدون وصله مانده مقاوم شویم
آسیب پذیری CVE-2026-50656 (RoguePlanet): یک آسیب‌پذیری Local Privilege Escalation در Microsoft Defender که به مهاجم دارای دسترسی محلی اجازه می‌دهد سطح دسترسی خود را تا SYSTEM افزایش دهد. مایکروسافت این آسیب‌پذیری را تأیید کرده، اما اعلام کرده که هنوز در حال توسعه وصله امنیتی است و تا این لحظه اصلاحیه رسمی منتشر نشده است. PoC نیز به‌صورت عمومی منتشر شده است.
بررسی کنیم چطور در سازمان در برابر این آسیب پذیری که در اثر اختلاف یک هکر و مایکروسافت زود منتشر شده و بدون وصله مانده مقاوم شویم
آسیب پذیری CVE-2026-50656 (RoguePlanet): یک آسیب‌پذیری Local Privilege Escalation در Microsoft Defender که به مهاجم دارای دسترسی محلی اجازه می‌دهد سطح دسترسی خود را تا SYSTEM افزایش دهد. مایکروسافت این آسیب‌پذیری را تأیید کرده، اما اعلام کرده که هنوز در حال توسعه وصله امنیتی است و تا این لحظه اصلاحیه رسمی منتشر نشده است. PoC نیز به‌صورت عمومی منتشر شده است.
👍5💯1
آکادمی آموزش روزبه 📚
آنچه که اکسپلویت آمده ولی وصله ندارد بررسی کنیم چطور در سازمان در برابر این آسیب پذیری که در اثر اختلاف یک هکر و مایکروسافت زود منتشر شده و بدون وصله مانده مقاوم شویم آسیب پذیری CVE-2026-50656 (RoguePlanet): یک آسیب‌پذیری Local Privilege Escalation در Microsoft…
حذف دسترسی‌های Local Administrator غیرضروری از کاربران و سرویس‌اکانت‌ها
محدود کردن قابلیت ساخت NTFS junction/symlink در مسیرهای قابل‌نوشتن توسط کاربر عادی (در حد امکان، با AppLocker/WDAC).
فعال‌سازی Attack Surface Reduction (ASR) rules در Defender خودش ،حتی اگر این مورد خاص را پوشش ندهد، سطح حمله‌ی کلی را پایین می‌آورد.
برای کشف:
ساخت NTFS junction یا symlink در مسیرهای قابل‌نوشتن کاربر مثل %TEMP%، %LOCALAPPDATA%، C:\ProgramData، کمی قبل از فعالیت
وmount شدن مشکوک فایل‌های virtual disk (.vhd, .vhdx)
اتصالات SMB خروجی به میزبان‌های نامعتبر
الگوهای غیرعادی در process lineage مربوط به MsMpEng.exe (مثلاً spawn شدن cmd.exe یا powershell.exe با ارث‌بری SYSTEM از پراسس Defender)
محدود کردن قابلیت ساخت NTFS junction/symlink در مسیرهای قابل‌نوشتن توسط کاربر عادی (در حد امکان، با AppLocker/WDAC).
فعال‌سازی Attack Surface Reduction (ASR) rules در Defender خودش ،حتی اگر این مورد خاص را پوشش ندهد، سطح حمله‌ی کلی را پایین می‌آورد.
برای کشف:
ساخت NTFS junction یا symlink در مسیرهای قابل‌نوشتن کاربر مثل %TEMP%، %LOCALAPPDATA%، C:\ProgramData، کمی قبل از فعالیت
وmount شدن مشکوک فایل‌های virtual disk (.vhd, .vhdx)
اتصالات SMB خروجی به میزبان‌های نامعتبر
الگوهای غیرعادی در process lineage مربوط به MsMpEng.exe (مثلاً spawn شدن cmd.exe یا powershell.exe با ارث‌بری SYSTEM از پراسس Defender)
👍5
طراحی MSSP
این روزها درحال طراحی معماری MSSP در شرکت هامون هستیم . نکاتی از اون رو براتون میگذارم
معماری Escalation در یک MSSP نباید بر اساس نوع قرارداد مشتری، بلکه بر مبنای شدت رخداد (Severity) طراحی شود. رخدادهای کم‌اهمیت می‌توانند از طریق تیکت و ایمیل مدیریت شوند، اما در رخدادهای بحرانی مانند باج‌افزار، تصاحب Domain Admin یا خروج گسترده اطلاعات، اطلاع‌رسانی فوری و چندکاناله باید برای همه مشتریان، صرف‌نظر از سطح قرارداد، انجام شود. همچنین، وجود مجوزهای از پیش توافق‌شده (Pre-Authorized Emergency Action) برای اجرای اقدامات حداقلی مهار، زمان واکنش را کاهش داده و مسئولیت حقوقی MSSP را شفاف می‌کند. بازبینی دوره‌ای فهرست تماس‌ها، مستندسازی دقیق همه تلاش‌های اطلاع‌رسانی و تعریف شفاف مسئولیت‌ها، از مهم‌ترین عوامل موفقیت این فرآیند و افزایش تاب‌آوری سایبری مشتریان هستند.
#هامون #MSSP
مقاله کامل را در لینک زیر در ویرگول بخوانید
https://vrgl.ir/Lbjko
این روزها درحال طراحی معماری MSSP در شرکت هامون هستیم . نکاتی از اون رو براتون میگذارم
معماری Escalation در یک MSSP نباید بر اساس نوع قرارداد مشتری، بلکه بر مبنای شدت رخداد (Severity) طراحی شود. رخدادهای کم‌اهمیت می‌توانند از طریق تیکت و ایمیل مدیریت شوند، اما در رخدادهای بحرانی مانند باج‌افزار، تصاحب Domain Admin یا خروج گسترده اطلاعات، اطلاع‌رسانی فوری و چندکاناله باید برای همه مشتریان، صرف‌نظر از سطح قرارداد، انجام شود. همچنین، وجود مجوزهای از پیش توافق‌شده (Pre-Authorized Emergency Action) برای اجرای اقدامات حداقلی مهار، زمان واکنش را کاهش داده و مسئولیت حقوقی MSSP را شفاف می‌کند. بازبینی دوره‌ای فهرست تماس‌ها، مستندسازی دقیق همه تلاش‌های اطلاع‌رسانی و تعریف شفاف مسئولیت‌ها، از مهم‌ترین عوامل موفقیت این فرآیند و افزایش تاب‌آوری سایبری مشتریان هستند.
#هامون #MSSP
مقاله کامل را در لینک زیر در ویرگول بخوانید
https://vrgl.ir/Lbjko
👍3👏2