چرا باید فرض کنیم سازمان از قبل هک شده است؟
یکی از مهم‌ترین تغییرات نگرش در امنیت سایبری، پذیرش اصل Assume Breach یا «فرض نفوذ» است. این رویکرد بیان می‌کند که هیچ سازمانی نمی‌تواند با اطمینان کامل ادعا کند هرگز مورد نفوذ قرار نخواهد گرفت. مهاجمان از آسیب‌پذیری‌های ناشناخته، خطاهای انسانی، سوءاستفاده از دسترسی‌های مجاز و حملات زنجیره تأمین استفاده می‌کنند؛ بنابراین، معماری امنیت باید بر این فرض طراحی شود که مهاجم ممکن است هم‌اکنون در بخشی از شبکه حضور داشته باشد.
مزیت این طرز فکر آن است که تمرکز سازمان از پیشگیری صرف، به کشف سریع، محدودسازی خسارت و بازیابی مؤثر تغییر می‌کند. در چنین رویکردی، ثبت لاگ، مانیتورینگ مداوم، Threat Hunting، مدیریت هویت، اصل حداقل دسترسی، تقسیم‌بندی شبکه و برنامه‌های پاسخ به حادثه اهمیت بیشتری پیدا می‌کنند. هدف این نیست که نفوذ هرگز رخ ندهد، بلکه باید زمان شناسایی مهاجم و مدت پاسخ‌گویی به حداقل برسد.
این نگرش، پایه بسیاری از چارچوب‌های مدرن مانند Zero Trust و معماری‌های دفاعی امروزی است. سازمانی که با فرض نفوذ طراحی می‌شود، حتی در صورت موفقیت مهاجم نیز توانایی بیشتری برای کنترل حمله، جلوگیری از حرکت جانبی، حفاظت از دارایی‌های حیاتی و تداوم کسب‌وکار خواهد داشت. در دنیای امروز، آمادگی برای مواجهه با نفوذ، واقع‌بینانه‌تر از اتکا به تصور نفوذناپذیری است.

اگر بتوانید این جملات را در سازمانتان بین مدیران فناوری و امنیت جا بیاندازید بدانید چند پله رشد را شاهد خواهید بود ✅

معماری امنیت بر پایه زمان؛ نگاهی به مدل TBS در پیشگیری، کشف و پاسخ

در بسیاری از سازمان‌ها، موفقیت امنیت سایبری با تعداد تجهیزات امنیتی یا بودجه صرف‌شده سنجیده می‌شود؛ اما مدل Time-Based Security (TBS) دیدگاه متفاوتی ارائه می‌دهد. این مدل که توسط Winn Schwartau معرفی شده است، امنیت را بر اساس سه مؤلفه زمانی ارزیابی می‌کند: زمان لازم برای نفوذ (Protection Time)، زمان لازم برای کشف حمله (Detection Time) و زمان لازم برای پاسخ و مهار (Response Time).

اصل اساسی TBS این است که اگر مجموع زمان کشف (TTD) و زمان پاسخ (TTR) کمتر از زمان موردنیاز مهاجم برای دستیابی به هدف (TTC) باشد، سازمان شانس بالایی برای جلوگیری از موفقیت حمله خواهد داشت. در مقابل، اگر مهاجم بتواند پیش از شناسایی و واکنش مدافع به اهداف خود برسد، حتی پیشرفته‌ترین کنترل‌های امنیتی نیز ارزش عملیاتی خود را از دست می‌دهند.

بر همین اساس، معماری امنیت نباید تنها بر پیشگیری متمرکز باشد. استفاده از EDR، SIEM، NDR، سامانه‌های Threat Detection، شبکه‌های تقسیم‌بندی‌شده، حسگرهای رفتاری و فرآیندهای Incident Response باید به‌صورت هم‌زمان طراحی شوند تا زمان کشف و واکنش کاهش یابد. این رویکرد شباهت زیادی به امنیت فیزیکی دارد؛ همان‌گونه که یک گاوصندوق بدون آژیر، دوربین و نیروی واکنش سریع نمی‌تواند امنیت کامل ایجاد کند.

مدل TBS به مدیران امنیت کمک می‌کند تا سرمایه‌گذاری‌های خود را بر اساس شاخص‌های قابل اندازه‌گیری مانند Mean Time to Detect (MTTD) و Mean Time to Respond (MTTR) اولویت‌بندی کنند. در نهایت، تاب‌آوری سایبری نه با تعداد ابزارها، بلکه با توانایی سازمان در شکست دادن مهاجم در رقابت با زمان سنجیده می‌شود.

**دوره CISSP #آکادمی_روزبه و شرکت #هامون

مایند ست و طرز تفکر خود و همکاران خود را تغییر دهید نیمی از مشکلات حل می‌شوند.
به جملات در نوشته ی فوق دقت کنید، چه زیبا میشود وقتی که همکاران و مدیران شما این جملات را با شما تکرار کنند و همفکر شما باشند

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

یکی از بهترین ریپوهای GitHub برای تست امنیت پروژه‌های Vibe Coding

https://github.com/1N3/Sn1per

درب پشتی در روتر ها

اینبار روتر های چینی
https://www.vulncheck.com/blog/zbt-endlessdoors

ابزار Ansible؛ ابزاری برای افزایش امنیت از طریق اتوماسیون

در بسیاری از سازمان‌ها، ضعف امنیتی نه به دلیل نبود ابزارهای پیشرفته، بلکه به علت اجرای ناهماهنگ و دستی تنظیمات امنیتی ایجاد می‌شود. Ansible با خودکارسازی این فرایندها، به کاهش خطای انسانی و افزایش یکپارچگی امنیت کمک می‌کند. این ابزار به مدیران اجازه می‌دهد تنظیمات امنیتی را به‌صورت Playbook تعریف کرده و آن‌ها را به شکل یکسان روی صدها یا هزاران سرور اجرا کنند.

یکی از مهم‌ترین کاربردهای Ansible، پیاده‌سازی Hardening سیستم‌عامل بر اساس استانداردهایی مانند CIS Benchmark است. همچنین می‌توان از آن برای نصب وصله‌های امنیتی، اعمال تنظیمات فایروال، مدیریت کاربران، استقرار Agentهای امنیتی مانند Wazuh یا Microsoft Defender و اجرای سیاست‌های امنیتی استفاده کرد. در زمان وقوع یک حادثه نیز Ansible می‌تواند بخشی از فرایند پاسخ به رخداد را خودکار کند؛ برای مثال، یک میزبان آلوده را از شبکه جدا کرده، سرویس خاصی را متوقف کند یا تنظیمات امنیتی جدیدی را اعمال نماید.

فرض کنید یک آسیب‌پذیری بحرانی در OpenSSH منتشر شده است. به‌جای ورود دستی به صدها سرور، کافی است یک Playbook اجرا شود تا وصله امنیتی روی تمام سامانه‌ها نصب، سرویس راه‌اندازی مجدد و نتیجه عملیات ثبت شود. به همین دلیل، Ansible امروزه یکی از ابزارهای کلیدی در DevSecOps، مدیریت پیکربندی و اتوماسیون امنیت به شمار می‌رود و نقش مهمی در افزایش سرعت، دقت و انطباق امنیتی سازمان‌ها ایفا می‌کند.

آینده EDRها؛ از تحلیل رویداد تا تحلیل گراف رفتار

نسل جدید سامانه‌های Endpoint Detection and Response (EDR) به‌تدریج از تشخیص مبتنی بر قوانین ثابت به سمت Graph AI و Sequence Models مانند Transformerها حرکت می‌کند. در این رویکرد، هدف تنها بررسی یک فایل، یک پردازش یا یک رویداد منفرد نیست؛ بلکه کل زنجیره فعالیت‌های سیستم به‌صورت یک گراف تحلیل می‌شود. ارتباط میان پردازش‌ها، فایل‌ها، رجیستری، ارتباطات شبکه، هویت کاربران و دسترسی‌ها در کنار یکدیگر بررسی می‌شوند تا رفتار واقعی سیستم درک شود.

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

این تحول، دقت کشف حملات Fileless، تکنیک‌های Living-off-the-Land (LOLBins) و تهدیدهای پیشرفته (APT) را به‌طور قابل‌توجهی افزایش می‌دهد؛ زیرا به‌جای تکیه بر یک Rule، رفتار کلی مهاجم و ارتباط میان رویدادها را تحلیل می‌کند. این همان مسیری است که مشاهده میشود نسل درحال تغییر EDRها بر پایه آن توسعه میابد.

قدرت واقعی TrendAIدر یک Driver یا Hook خاص نیست؛ بلکه در کیفیت تله‌متری و همبستگی داده‌هاست.

**منبع : تلاش چند ماهه در شناخت رفتاری #ترند_میکرو توسط تیمMSSP #هامون Haumoun

برداشت من از مقاله زیر

در SOC فقط تهدید را مانیتور نکنیم؛ سلامت Telemetry را هم مانیتور کنیم

یکی از اصول مهم در Detection Engineering، اطمینان از سلامت Telemetry است. سؤال فقط این نیست که چه Eventهایی دریافت کرده‌ایم؟؛ بلکه باید بپرسیم: آیا Eventهایی که انتظار داشتیم، واقعاً دریافت شده‌اند؟

برای این کار می‌توان از Heartbeat استفاده کرد تا مشخص شود Agentهایی مانند EDR، Sysmon یا Splunk Forwarder همچنان فعال‌اند. همچنین با ایجاد Event Volume Baseline می‌توان کاهش غیرعادی حجم رویدادها را تشخیص داد؛ مثلاً Domain Controller که معمولاً هزاران Event تولید می‌کند، نباید ناگهان تقریباً ساکت شود.

روش دیگر، بررسی Expected Events است. اگر سرور فعال است اما Process Creation Event دریافت نمی‌شود، باید سلامت Telemetry بررسی شود. Cross-source Correlation نیز اهمیت زیادی دارد؛ برای مثال Network Telemetry فعالیت یک Host را نشان می‌دهد، اما EDR درباره همان Host ساکت است.

علاوه بر Agentها، کل زنجیره تا خود رول
باید مانیتور شود. حتی می‌توان Synthetic Event ایجاد کرد و رسیدن آن به Detection Engine را سنجید.

بنابراین Detection Engineering بالغ دو حوزه دارد:

Detection of Malicious Activity + Detection of Loss of Visibility

گاهی خطرناک‌ترین Event در SOC، Eventی است که باید می‌آمد، اما نیامده است.




https://blog.otterpwn.com/research/In-depth-Windows-Telemetry

#درس_آموخته

یک Mobile Application نباید فرض کند:
چون Certificate Pinning دارم، کسی نمی‌تواند API من را مشاهده یا دستکاری کند.

سمت Server همچنان باید Authentication، Authorization، Session Management، Rate Limiting و Input Validation را مستقل و درست انجام دهد.

https://coffsec.medium.com/10-methods-to-bypass-ssl-certificate-pinning-on-mobile-in-2026-54b21141da80

پاک شدن Log به معنی پاک شدن Evidence نیست


یکی از تکنیک‌های رایج مهاجمان پس از نفوذ به سیستم‌های Linux، پاک کردن Logها برای از بین بردن ردپا است.
برای مثال، مهاجم ممکن است پس از ورود از طریق SSH فایل /var/log/auth.log را حذف یا خالی کند و تصور کند شواهد ورود او از بین رفته است.

اما در سیستم‌های مبتنی بر systemd، تحلیلگر فارنزیک نباید Investigation را در همین نقطه متوقف کند. سرویس systemd-journald می‌تواند همان فعالیت‌ها را در Journal خود ثبت کرده باشد.
برای مثال، می‌توان فعالیت‌های مرتبط با sshd را با دستور زیر بررسی کرد:
journalctl _COMM=sshd
همچنین با since-- می‌توان محدوده زمانی Investigation را مشخص کرد. حتی journalctl --file امکان تحلیل فایل Journal استخراج‌شده از یک سیستم یا Disk Image دیگر را فراهم می‌کند.

البته باقی‌ماندن این شواهد قطعی نیست. journald ممکن است به‌صورت Persistent در /var/log/journal یا به‌صورت Volatile در /run/log/journal کار کند؛ حالت Volatile با Reboot از بین می‌رود.

درس مهم برای Incident Response این است:
هر رویداد ممکن است در چند Evidence Source ردپا داشته باشد.

مهاجم شاید auth.log را پاک کند، اما هنوز ممکن است شواهدی در journald، auditd، SIEM، EDR، Firewall یا سایر منابع مرکزی باقی مانده باشد.

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

آشنایی با یکی از مدرسین دوره SOCT1
پیش نیاز دوره مهندسی کشف

🌼جناب مهندس کیانوش حبیبی
Kianoush Habibi Sesari
مدیر MSSP شرکت هامون
مدیر سابق SOC کاریزما

🌸برای آشنایی با نحوه تدریس ایشان به ویدئو های دوره CIS Controls در آپارات آکادمی روزبه مراجعه نمایید

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

🌹آینده شما در امنیت سایبری از قدمهای امروز شما رقم می‌خورد

🟢با آکادمی روزبه کیفیت آموزش را معنا میکنیم

درمورد OEM و Supply chain که در جلسات CISSP صحبت شد

در ارزیابی Technology Supply Chain Risk، دانستن کشور سازنده محصول تنها نقطه شروع است، نه پایان تحلیل ریسک. یک تجهیز ممکن است با برند یک شرکت معتبر عرضه شود، اما سخت‌افزار آن توسط OEM دیگری تولید شده، Firmware آن توسط پیمانکار ثالث توسعه یافته یا برخی ماژول‌های ارتباطی آن از زنجیره‌ای کاملاً متفاوت تأمین شده باشند.

بنابراین سازمان پیش از ورود تجهیزات حساس به زیرساخت باید بپرسد: OEM واقعی چه کسی است؟ مالک و توسعه‌دهنده Firmware کیست؟ Firmware چگونه Sign و Update می‌شود؟ آیا Secure Boot فعال است؟ چه ماژول‌های Wi-Fi، Bluetooth، Cellular یا Management Interface در تجهیز وجود دارد؟

حتی مهم‌تر، باید بررسی شود آیا دستگاه می‌تواند خارج از مسیرهای ارتباطی تعریف‌شده در معماری سازمان، یک Out-of-Band Communication Channel ایجاد کند.

اصل مهم این است که Vendor Trust جایگزین Technical Verification نیست. امنیت زنجیره تأمین زمانی واقعی می‌شود که منشأ، Firmware، اجزا، مسیرهای ارتباطی و مکانیزم‌های به‌روزرسانی محصول مستقل از ادعاهای Vendor بررسی شوند.

https://news.risky.biz/risky-bulletin-slovakia-finds-russian-backdoor-in-traffic-speed-cameras/

واتس اپ و بله 09902857290

فراخوان همکاری شرکت‌ها در جذب و استخدام دانشجویان آکادمی روزبه

شرکت هامون در راستای حمایت از توسعه سرمایه انسانی متخصص در حوزه امنیت سایبری، تصمیم گرفته است زمینه استخدام برترین دانشجویان دوره‌های آکادمی روزبه را فراهم کند. همچنین هامون در حال حاضر با تقبل ۲۰ درصد از هزینه دوره‌های آموزشی آکادمی روزبه، امکان بهره‌مندی دانشجویان از این تخفیف را فراهم کرده است.

با توجه به کیفیت آموزشی دوره‌ها، رویکرد کاربردی و ارتباط آموزش‌ها با نیازهای واقعی صنعت، انتظار داریم فارغ‌التحصیلان برتر آکادمی روزبه بتوانند به نیروهایی توانمند و مؤثر، به‌ویژه در حوزه‌های SOC، Blue Team و امنیت سایبری تبدیل شوند.

🌸اما هدف این طرح صرفاً تأمین نیروی انسانی شرکت هامون نیست.

✅️ما علاقه‌مندیم سایر شرکت‌های فعال در صنعت امنیت سایبری نیز بتوانند از این ظرفیت استفاده کنند. از این رو، از شرکت‌های همکار، ارائه‌دهندگان خدمات امنیت، مراکز SOC و سازمان‌هایی که نیازمند جذب نیروی متخصص هستند دعوت می‌کنیم نیازهای استخدامی و تخصص‌های موردنظر خود را از هم‌اکنون به آکادمی روزبه اعلام کنند.

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

این همکاری می‌تواند یک مسیر دوطرفه ایجاد کند: دانشجویان با چشم‌انداز روشن‌تری وارد مسیر آموزش و اشتغال شوند و شرکت‌ها نیز به مجموعه‌ای از نیروهای آموزش‌دیده و ارزیابی‌شده دسترسی پیدا کنند.

از شرکت‌های فعال در حوزه SOC و امنیت سایبری دعوت می‌کنیم به این فراخوان بپیوندند و نیازهای استخدامی خود را اعلام کنند.

آموزش باکیفیت، شناسایی استعدادها و اتصال آنها به صنعت؛ مسیری که می‌تواند هم برای دانشجو و هم برای کارفرما ارزش‌آفرین باشد.

واتس اپ و بله 09902857290

چرا Zeek برای مهندسی کشف ضروری است؟

یکی از مهم‌ترین اصول در Detection Engineering این است که پیش از نوشتن هر Rule از خود بپرسیم: Telemetry این رفتار کجاست؟ در بسیاری از حملات، پاسخ این سؤال در Network Telemetry قرار دارد و Zeek یکی از قدرتمندترین ابزارها برای تولید چنین داده‌ای است.

ابزار Zeek را نباید صرفاً یک IDS دانست. وظیفه مهم آن تبدیل ترافیک شبکه به مجموعه‌ای از داده‌های ساخت‌یافته و قابل تحلیل است. لاگ‌هایی مانند "conn.log"، "dns.log"، "http.log"، "ssl.log" و "files.log" به Detection Engineer اجازه می‌دهند رفتار ارتباطات شبکه را بدون وابستگی کامل به Payload مشاهده کند.

برای مثال، در کشف C2 Beaconing می‌توان تناوب ارتباطات، مقصد، مدت Session و حجم داده را بررسی کرد. در DNS Tunneling نیز طول Query، تعداد Subdomainها، Frequency و الگوهای غیرعادی DNS می‌توانند Telemetry لازم برای Detection را فراهم کنند.

تفاوت مهم Zeek با IDSهای Signature-based نیز همین‌جاست: سؤال اصلی فقط این نیست که «آیا ترافیک با یک Signature تطبیق دارد؟» بلکه این است که «در شبکه چه رفتاری اتفاق افتاده است؟»

در دنیای تجاری، Corelight نزدیک‌ترین گزینه به این فلسفه است. محصولاتی مانند ExtraHop و Vectra AI نیز بخشی از این نیاز را در قالب NDR پوشش می‌دهند.

یک Detection خوب از Rule شروع نمی‌شود؛ از شناخت رفتار مهاجم و پیدا کردن Telemetry مناسب آغاز می‌شود.

**دوره مهندسی کشف آکادمی روزبه

چطور در دوره SOC T1 می‌آموزیم؟

مثال : WMI چیست و چه مساله ای ما با او داریم


پروتکل WMI یا Windows Management Instrumentation را می‌توان زبان مشترک مدیریت ویندوز دانست.

پروتکل WMI به برنامه‌ها، مدیران شبکه و اسکریپت‌ها اجازه می‌دهد از ویندوز اطلاعات بگیرند یا برخی کارها را از راه دور و محلی انجام دهند؛ مثلاً:

چه پردازش‌هایی در حال اجرا هستند؟

سیستم چه IP و مقدار RAM دارد؟

چه سرویس‌هایی فعال‌اند؟

آیا می‌توان یک سرویس را متوقف کرد؟

آیا می‌توان برنامه‌ای را روی سیستم دیگری اجرا کرد؟


مثلاً مدیر شبکه با WMI وضعیت صدها کامپیوتر را بدون مراجعه حضوری بررسی می‌کند. اما مهاجم هم ممکن است از همین قابلیت قانونی برای شناسایی سیستم، اجرای فرمان، حرکت جانبی و ایجاد ماندگاری استفاده کند.

پس WMI ذاتاً بدافزار نیست؛ یک ابزار مدیریتی قدرتمند است که استفاده غیرعادی از آن باید پایش شود.

تشبیه ساده: WMI مثل میز اطلاعات و کنترل ویندوز است؛ سؤال می‌پرسید، اطلاعات می‌گیرید و اگر مجوز داشته باشید، دستور هم اجرا می‌کنید.

مثال تاریخی


حمله Olympic Destroyer در المپیک زمستانی ۲۰۱۸

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

حالا چطور سوء استفاده رو کشف کنیم ؟👇👇