OWASP Code review guide 2.0

آیا GPS یک کانال مخفی نظامی دارد؟


خلاصه مطلب مندرج در لینک زیر زبان ساده:

پژوهشگری به نام Steven Murdoch و تیمش بخشی از پیام‌های ناوبری GPS را بررسی کرده‌اند.
این بخش شامل ۱۷۶ بیت داده است که در مستندات رسمی GPS فقط به‌عنوان محتوای اختیاری (Discretionary Content) معرفی شده و کاربرد مشخصی برای آن اعلام نشده است.
آن‌ها بیش از ۱۲ میلیون نمونه پیام GPS را از سال ۲۰۰۷ تا ژانویه ۲۰۲۶ تحلیل کردند.
نتیجه تحلیل آماری نشان داد که این داده‌ها شبیه اطلاعات رمزنگاری‌شده رفتار می‌کنند و تصادفی نیستند.
نکته جالب‌تر اینکه در ۲۶ مه ۲۰۱۱ تمام ماهواره‌های فعال GPS تقریباً هم‌زمان از ارسال الگوهای آزمایشی ساده (0xAA) به ارسال این داده‌های مبهم تغییر کرده‌اند.
این تاریخ با اسناد منتشرشده مربوط به OTAD (Over-The-Air Distribution) هم‌زمان است؛ روشی که برای ارسال از راه دور کلیدهای رمزنگاری به تجهیزات نظامی استفاده می‌شود.

آیا این یعنی GPS یک «کانال مخفی» نظامی دارد؟

هنوز خیر. پژوهشگران فقط گفته‌اند که این داده‌ها احتمالاً کاربرد رمزنگاری دارند و ممکن است برای توزیع کلیدهای امنیتی استفاده شوند. اما هیچ نهاد رسمی آمریکایی این موضوع را تأیید یا رد نکرده است.


نکته امنیتی جالب

این موضوع یادآوری می‌کند که بسیاری از زیرساخت‌های حیاتی، علاوه بر کارکرد عمومی، ممکن است دارای قابلیت‌های امنیتی یا مدیریتی مستندنشده باشند. البته تا این لحظه، این یافته بیشتر یک فرضیه علمی مبتنی بر تحلیل آماری قوی است و نه مدرکی قطعی از وجود یک کانال مخفی در GPS.



https://andreafortuna.org/2026/06/09/gps-numbers-station/

هرجا SOC دست من باشد ، سه اقدام فوری انجام می‌دهم:

#تجربه

استخراج کامل Driver Inventory از تمام Endpointها؛
تطبیق هفتگی با LOLDrivers و Microsoft Blocklist؛
ساخت Use Case برای کشف بارگذاری Driverهای مشکوک در SIEM.

** حد و اندازه این عملیات به بلوغ سازمان هدف وابسته است

پیشنهاد هایی به افتای ریاست جمهوری کشور از تصمیم جدید CISA

تصمیم جدید CISA برای بازنویسی الزامات مدیریت وصله‌های امنیتی، صرفاً کاهش زمان نصب Patch از ۱۵ روز به ۳ روز نیست؛ بلکه نشانه تغییر یک پارادایم مهم در مدیریت آسیب‌پذیری است. این تغییر می‌تواند برای افتا نیز الهام‌بخش باشد.

۱. عبور از Patch Everything به Patch Smarter

سال‌ها بسیاری از سازمان‌ها تلاش کردند همه آسیب‌پذیری‌ها را با یک فوریت یکسان رفع کنند. اما CISA پذیرفته است که در عصر هوش مصنوعی، این رویکرد عملی نیست. بر این اساس، آسیب‌پذیری‌ها بر اساس ریسک واقعی اولویت‌بندی می‌شوند.

۲. ایجاد نسخه ایرانی KEV

یکی از مهم‌ترین درس‌ها، توسعه یک فهرست ملی آسیب‌پذیری‌های مورد سوءاستفاده مشابه KEV است؛ فهرستی که بر اساس تهدیدات واقعی علیه زیرساخت‌های کشور به‌روزرسانی شود و به دستگاه‌ها بگوید کدام CVEها باید فوراً اصلاح شوند.

۳. توجه به قابلیت بهره‌برداری خودکار توسط AI

سازمان CISA برای نخستین بار، قابلیت خودکارسازی حمله را به‌عنوان معیار اولویت‌بندی وارد کرده است. یعنی اگر یک آسیب‌پذیری به کمک AI بتواند در مقیاس وسیع و بدون دخالت زیاد انسان مورد سوءاستفاده قرار گیرد، باید سریع‌تر رفع شود.

۴. الزام به تحلیل فارنزیک

نکته مهم دیگر این است که وصله کردن کافی نیست. در آسیب‌پذیری‌های بحرانی، دستگاه‌ها باید بررسی کنند آیا پیش از نصب وصله، نشانه‌ای از نفوذ وجود داشته است یا خیر. این موضوع می‌تواند به الزامی برای انجام Forensic Triage در زیرساخت‌های حیاتی کشور تبدیل شود.

۵. دارایی‌محوری به جای CVE محوری

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

۶. استانداردسازی برچسب‌گذاری دارایی‌ها

سازمان CISA اعلام کرده است که برای دارایی‌ها Schema استاندارد منتشر خواهد کرد. این موضوع می‌تواند افتا را به سمت ایجاد یک مدل ملی طبقه‌بندی دارایی‌ها و یکپارچه‌سازی CMDB سازمان‌های حیاتی سوق دهد.

۷. حرکت به سمت Exposure Management

شاید مهم‌ترین پیام این تصمیم آن باشد که دوران Vulnerability Management سنتی رو به پایان است. در آینده، سؤال اصلی این نیست که "چند آسیب‌پذیری داریم؟" بلکه این است که "کدام آسیب‌پذیری روی کدام دارایی حیاتی، با چه احتمال بهره‌برداری و چه اثر عملیاتی، بیشترین خطر را ایجاد می‌کند؟"

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

https://www.darkreading.com/cyber-risk/cisa-rewrites-federal-patching-requirements-ai-threat-era?utm_campaign=Oktopost-2025-09+Native+Posts&utm_content=Oktopost-LinkedIn&utm_medium=social&utm_source=LinkedIn

👆👆بیش از 9 سال با اسپلانک در آکادمی روزبه


حدود ۹ سال پیش شروع نگارش در مورد splunk را در آکادمی روزبه داشتیم و کلاسهای متعددی برگزار شد
و
پیرو آن در آن زمان کتاب اسپلانک چاپ شد

مدل‌های Mythos-Class؛ آغاز عصر جدید در امنیت سایبری

در دو دهه گذشته، فناوری‌هایی مانند تراشه‌های پیشرفته، سامانه‌های رمزنگاری نظامی و تجهیزات سایبری تهاجمی به عنوان دارایی‌های راهبردی کشورها شناخته می‌شدند. اکنون نسل جدید مدل‌های هوش مصنوعی موسوم به Mythos-Class نیز در حال پیوستن به همین دسته هستند. دلیل این موضوع تنها قدرت پردازشی یا توانایی تولید محتوا نیست؛ بلکه ظرفیت این مدل‌ها برای تحلیل، تصمیم‌گیری و تولید دانش تخصصی در حوزه‌هایی مانند امنیت سایبری است.
برخلاف نسل‌های پیشین هوش مصنوعی که عمدتاً نقش دستیار را ایفا می‌کردند، مدل‌های جدید قادرند حجم عظیمی از داده‌های امنیتی را تحلیل کرده، فرضیه‌های هانتینگ تولید کنند، قواعد تشخیص حمله را بنویسند و حتی در کشف آسیب‌پذیری‌های ناشناخته مشارکت داشته باشند. این قابلیت‌ها باعث شده است مرز میان ابزار تحلیل و تحلیلگر امنیتی به تدریج کمرنگ شود.
برای مراکز عملیات امنیت ، تیم‌های Threat Hunting و متخصصان DFIR، مهم‌ترین تحول ناشی از این فناوری، ظهور مفهوم همکار تحلیلی دیجیتال است. در چنین مدلی، هوش مصنوعی نه تنها داده‌ها را جمع‌آوری و طبقه‌بندی می‌کند، بلکه می‌تواند زنجیره حمله را بازسازی کرده، رفتار مهاجم را تفسیر کند و پیشنهادهای عملیاتی ارائه دهد. این موضوع می‌تواند زمان تشخیص و پاسخ به حوادث را از چند روز به چند ساعت یا حتی چند دقیقه کاهش دهد.
با این حال، همین توانایی‌ها ماهیتی دوگانه دارند. مدلی که قادر به کشف آسیب‌پذیری برای اهداف دفاعی است، می‌تواند در اختیار مهاجمان نیز به ابزاری برای توسعه حملات پیچیده تبدیل شود. به همین دلیل دولت‌ها و نهادهای امنیتی به این فناوری‌ها با دیدگاهی مشابه فناوری‌های راهبردی و صادرات‌محور نگاه می‌کنند.
به نظر می‌رسد در آینده نزدیک، مزیت رقابتی سازمان‌ها دیگر تنها در اختیار داشتن داده یا ابزارهای امنیتی نخواهد بود، بلکه در میزان دسترسی و بهره‌برداری مؤثر از مدل‌های هوش مصنوعی پیشرفته‌ای خواهد بود که می‌توانند نقش یک تحلیلگر خبره را در مقیاس وسیع ایفا کنند.

https://edition.cnn.com/2026/06/13/business/anthropic-mythos-model-national-security
لینک خبر ممانعت دولت آمریکا از دسترسی به برخی مدل‌های هوش مصنوعی

این مستند با عنوان «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/