این مستند با عنوان «Software Bill of Materials for AI — Minimum Elements»، یک راهنمای تخصصی است که توسط نهادهای امنیت سایبری کشورهای عضو G7 و اتحادیه اروپا تدوین شده است. هدف اصلی این سند، ارتقای شفافیت در سیستم‌های هوش مصنوعی از طریق استانداردسازی «فهرست اجزای نرم‌افزاری» (SBOM) است.

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

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

مقاله جذاب امروز

https://www.cybertriage.com/blog/wmi-malware/

مدل بلوغ امنیت AI

مستندی از سنز

طوفان ذهنی در خصوص اختلال بانکها


**تمام این بحث برپایه فرضیات، تجربه و مفاهیم ISSAP است چون در پروژه ای که خودم درگیر باشم موضوعات رو نمیتونم شفاف و به روز عیان کنم .


از منظر یک متخصص معمار ارشد امنیت سایبری (ISSAP) ، رخداد نفوذ به یک شرکت ارائه‌دهنده خدمات و تأثیر همزمان آن بر چهار بانک، بیش از آنکه یک ضعف فنی باشد ، میتواند نشانه یک نقص در معماری امنیتی باشد. در معماری‌های امن، اصل بر این است که رخنه در یک بخش نباید بتواند کل اکوسیستم را تحت تأثیر قرار دهد. اگر نفوذ به یک تأمین‌کننده باعث اختلال در چند بانک شده باشد، احتمالاً مرزهای اعتماد (Trust Boundaries) به‌درستی تعریف نشده‌اند و سطح جداسازی منطقی میان مشتریان کافی نبوده است.

یکی از دلایل رایج چنین رخدادهایی، استفاده از زیرساخت مدیریتی مشترک، حساب‌های مدیریتی مشترک یا سرویس‌های متمرکز برای چند مشتری است. در این شرایط، مهاجم پس از نفوذ به محیط ارائه‌دهنده خدمات می‌تواند به سایر سامانه‌ها نیز دسترسی پیدا کند یا باعث اختلال زنجیره‌ای شود. همچنین نبود Network Segmentation، Micro-Segmentation و کنترل‌های Zero Trust می‌تواند امکان حرکت جانبی (Lateral Movement) را برای مهاجم فراهم کند.

در یک طراحی امنیتی صحیح، هر بانک باید به‌عنوان یک دامنه امنیتی مستقل در نظر گرفته شود؛ به‌گونه‌ای که حتی در صورت رخنه کامل به شرکت ارائه‌دهنده خدمات، دامنه اثر حادثه محدود باقی بماند. بنابراین مهم‌ترین یافته معماری در چنین رخدادی، عدم کنترل Blast Radius و نبود مکانیزم‌های مؤثر برای ایزوله‌سازی مشتریان و سرویس‌های حیاتی است؛ موضوعی که مستقیماً با اصول تاب‌آوری سایبری و معماری امن در ISSAP در ارتباط است.

👆👆مدرک ISSAP (Information Systems Security Architecture Professional) یکی از تخصص‌های پیشرفته خانواده مدارک CISSP است که توسط سازمان ISC2 ارائه می‌شود. این مدرک بر طراحی و معماری امنیت سازمانی تمرکز دارد و برای معماران امنیت، مشاوران ارشد و مدیران فنی مناسب است. حوزه‌های اصلی آن شامل طراحی معماری امنیتی، مدیریت ریسک، مدل‌های اعتماد، امنیت زیرساخت، یکپارچه‌سازی کنترل‌های امنیتی و هم‌راستاسازی امنیت با اهداف کسب‌وکار است. دارنده ISSAP می‌تواند معماری امنیتی را در سطح سازمان طراحی، ارزیابی و بهبود دهد و اطمینان حاصل کند که الزامات امنیتی در سامانه‌ها و پروژه‌ها از مرحله طراحی لحاظ شده‌اند.

#درسی_از_دیگران

توصیه به مرکز افتا و شاپرک: گذار از مدیریت لاگ به مدیریت شواهد امنیتی

با افزایش پیچیدگی تهدیدات سایبری، صرف جمع‌آوری و نگهداری لاگ دیگر معیار کافی برای ارزیابی امنیت سازمان‌ها نیست. پیشنهاد می‌شود افتا‌و شاپرک در بازنگری الزامات امنیتی کشور ، رویکرد Evidence-Centric Security را مدنظر قرار دهد؛ یعنی سازمان‌ها علاوه بر نگهداری لاگ، توانایی تولید شواهد قابل استناد از عملکرد کنترل‌های امنیتی خود را نیز داشته باشند.

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

این تحول می‌تواند الزامات جدیدی نظیر نگاشت Detectionها به ATT&CK، ثبت فرآیند Threat Hunting، مدیریت پرونده‌های رخداد (Case Management) و نگهداری Audit Trail تصمیمات امنیتی را در زیرساخت‌های حیاتی کشور الزامی کند. نتیجه این رویکرد، افزایش تاب‌آوری سایبری و امکان اثبات اثربخشی واقعی کنترل‌های امنیتی در برابر ممیزان و نهادهای نظارتی خواهد بود.
https://medium.com/the-visibility-layer/the-government-just-redefined-what-log-management-is-for-545633f6a1e3

قبل از سونامی!!


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

پس چه باید کرد ؟

طراحی Use Caseهای مستقل در SOC برای شناسایی Backup Deletion، Shadow Copy Deletion، EDR Tampering و Mass File Modification انجام دهید.

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

#MSSP #هامون

#خط_مشی

مقوله AI-Powered Zero Trust؛ گام بعدی در تحول امنیت سایبری کشور

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

پیشنهاد می‌شود مرکز مدیریت راهبردی افتا، چارچوب AI-Powered Zero Trust را به‌عنوان نسل بعدی الزامات امنیتی کشور مورد توجه قرار دهد. در این رویکرد، تصمیمات امنیتی صرفاً بر اساس قوانین از پیش تعریف‌شده اتخاذ نمی‌شوند، بلکه سامانه‌های هوشمند به‌صورت مستمر رفتار کاربران، تجهیزات، نرم‌افزارها و جریان‌های داده را تحلیل کرده و سطح ریسک را به‌صورت لحظه‌ای محاسبه می‌کنند.

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

در سطح سیاست‌گذاری ملی، پیشنهاد می‌شود کلیه دستگاه‌های مشمول افتا ملزم به استقرار سازوکارهای Continuous Verification، Risk-Based Access Control، تحلیل رفتاری مبتنی بر هوش مصنوعی و یکپارچه‌سازی سامانه‌های IAM، PAM، SIEM، EDR و XDR شوند. همچنین الزامات حاکمیت و ممیزی مدل‌های هوش مصنوعی باید به‌عنوان بخشی از چارچوب امنیتی کشور تعریف گردد.

بحث AI-Powered Zero Trust یک فناوری جدید نیست، بلکه تکامل منطقی معماری Zero Trust برای مواجهه با تهدیدات عصر هوش مصنوعی است. اتخاذ این رویکرد می‌تواند یکی از ارکان اصلی افزایش تاب‌آوری سایبری زیرساخت‌های حیاتی کشور در دهه آینده باشد.


https://www.govconwire.com/articles/chuck-brooks-govcon-expert-ai-quantum-computing-zero-trust-cybersecurity

برای علاقمندان به فارنزیک

با تشکر از خانم کسانی

این مقاله با عنوان Interpol review of forensic image and video analysis, 2022–2025مروری بر تازه‌ترین پیشرفت‌های تحلیل فارنزیک تصویر و ویدئو است. نویسندگان نشان می‌دهند که از سال ۲۰۲۲ به بعد، هوش مصنوعی و یادگیری عمیق به‌شدت این حوزه را تغییر داده‌اند؛ به‌ویژه در بهبود تصویر، تشخیص اصالت، شناسایی منبع دوربین، کشف جعل، تحلیل بیومتریک، تحلیل راه‌رفتن (gait) و فتوگرامتری. در عین حال، مقاله هشدار می‌دهد که مدل‌های مولد ممکن است جزئیات ساختگی ایجاد کنند و اگر بدون کنترل استفاده شوند، اعتبار شواهد را کاهش دهند. یکی از نکات مهم مقاله این است که روش‌های قدیمی مانند PRNU در دستگاه‌های جدید محدودیت‌هایی دارند و روش‌های جدید باید با شفافیت، اعتبارسنجی و قابلیت توضیح همراه باشند. این مطالعه بر پایه جست‌وجو در Google Scholar و Scopus انجام شده و نتیجه اصلی آن این است که پیشرفت‌ها سریع‌اند، اما استانداردها و معیارهای حقوقی هنوز عقب‌تر هستند.

**برای دانشجویانم در دانشگاه پلی تکنیک ؛ امیرکبیر

امنیت کانتینر
درس جدید در این دوره از کلاس CISSP

بسیاری از ما در کانتینرها بر روی حفاظت از Control Plane تمرکز می‌کنیم، در حالی که در دنیای واقعی مهاجم اغلب از طریق یک برنامه آسیب‌پذیر در Data Plane وارد می‌شود. مثلاً یک RCE در وب‌سرور، API یا برنامه Front-End.

پس از ورود به یک Pod، مهاجم تلاش می‌کند به سایر Podها، Nodeها یا حتی Control Plane حرکت جانبی (Lateral Movement) انجام دهد.

🔴 سه ریسک اصلی در این بین چیه :

1️⃣سوءاستفاده از Service Accountها و مجوزهای RBAC

2️⃣فرار از Container (Container Escape)

3️⃣ایمیج آلوده و Supply Chain

🟢راهکار:


🔆جداسازی Workloadهای مرتبط با وب در Namespaceهای مستقل

🔆اعمال Least Privilege روی Service Accountها

🔆استفاده از Pod Security Standards

🔆اعمال Network Policy برای محدود کردن ارتباط Podها

🔆اعتبارسنجی و امضای Container Imageها

🔆استفاده از Sandboxهایی مانند Kata Containers و gVisor در محیط‌های حساس.
🔆استفاده از ایجنت های XDR نظیر TrendAI

مقوله 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/

چالش این جمعه

موتور پیش بینی گوگل

قابل اجرا روی ماشین خودتون

https://github.com/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 و آموزش مدل‌های هوش مصنوعی امنیتی استفاده کرد. به همین دلیل، داده‌های مصنوعی در حال تبدیل شدن به یکی از ارکان مهم نسل جدید عملیات امنیت هستند.

خبر مهم و وظیفه ما

با توجه به انقضای بخشی از گواهی‌ها و کلیدهای قدیمی 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/

تمرین فارنزیک

آزمایشگاه

https://theevidencelocker.github.io/

#درس دوشنبه صبح در سازمان

در بسیاری از تیم‌های DFIR پیشرفته، Velociraptor برای شناسایی در سطح سازمان و KAPE برای جمع‌آوری عمیق شواهد از سیستم‌های منتخب استفاده می‌شود.

دوره CISSP از هفته دوم تیر شروع میشود

ثبت نام از طریق بله 09902857290

مقوله Cascade Failure؛ تهدیدی که معماری ضعیف امنیت حوزه بانکی را آشکار می‌کند

از نگاه یک معمار امنیت و متخصص CISSP، بزرگ‌ترین خطر برای زیرساخت‌های بانکی الزاماً یک آسیب‌پذیری بحرانی نیست، بلکه Cascade Failure یا خرابی آبشاری است. در این حالت، اختلال در یک مؤلفه مانند سرویس هویت، ذخیره‌ساز مرکزی، لینک ارتباطی یا حتی سامانه EDR می‌تواند به دلیل وابستگی‌های معماری، به توقف زنجیره‌ای ده‌ها سرویس حیاتی منجر شود. نتیجه آن می‌تواند از کار افتادن اینترنت بانک، خودپردازها، سامانه‌های پرداخت، مراکز تماس و حتی ابزارهای مانیتورینگ باشد. معماری امنیتی باید با حذف نقاط تکین خرابی (Single Point of Failure)، جداسازی دامنه‌های عملیاتی، طراحی افزونگی (Redundancy)، محدودسازی Blast Radius و آزمون‌های منظم تاب‌آوری، از گسترش این اختلال جلوگیری کند. در واقع، امنیت معماری تنها به جلوگیری از نفوذ محدود نمی‌شود؛ بلکه تضمین می‌کند که حتی در صورت رخداد حمله یا خرابی، کل اکوسیستم بانکی دچار فروپاشی زنجیره‌ای نشود و خدمات حیاتی با کمترین اختلال ادامه یابد.


ثبت نام دوره CISSP از طریق بله 09902857290
#همیشه_بخوان
#آکادمی_روزبه

#بحث فلسفی روز تعطیل

وقتی مایکروسافت برای 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 کاملاً رسمی و مجاز.

درسهای مدیریت با شفقت

کتاب قدرت شفقت ورزی ، انتشارات آریانا

دیوید بیانکو (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