آکادمی آموزش روزبه 📚

دوره های درحال ثبت نام آکادمی روزبه و شرکت هامون 1⃣مبانی فناوری و امنیت با مروری بر دوره های زیر Security+ MCSA LPIC1 CCNA CEH 2️⃣دوره مدیریت و راهبری اسپلانک و ES با تمرکز بر نصب کلاستر ، کوئری های پیشرفته و ES 3️⃣دوره معماری ارشد امنیت ISSAP 4️⃣دوره مدیریت ارشد امنیت؛ CISO سرفصل ISSMP 5️⃣دوره مدرک عالی امنیت CISSP ✅ثبت نام و اطلاع بیشتر از طریق واتس اپ 09902857290 Www.haumoun.com

👆👆چطور تولید کنندگان معتبر دنیای IT هم با اصول ISSAP فاصله دارند ؟ از منظر معماری امنیت در ISSAP، می‌توان دو انتخاب تاریخی ویندوز را نقد کرد؛ البته ISSAP استاندارد طراحی سیستم‌عامل نیست و تعبیر «مغایرت با اصول معماری امنیت» دقیق‌تر است. نمونه ای از رفتار مایکروسافت که مغایر متن درسی ISSAP است. ❇️ حفاظت ناکافی از اسرار احراز هویت: در معماری سنتی ویندوز، اسراری مانند هش NTLM و بلیت‌های Kerberos در حافظه فرایند LSASS نگهداری می‌شدند. مهاجمی که دسترسی ممتاز و امکان خواندن این حافظه را کسب می‌کرد، می‌توانست با ابزارهایی مانند Mimikatz اعتبارنامه‌ها را استخراج کند. نقد معماری، صرفاً وجود یک ابزار حمله نیست؛ مسئله این است که تسلط بر محیط اجرایی سیستم‌عامل می‌توانست به تسلط بر اسرار هویتی تبدیل شود. این وضعیت با اصول جداسازی، دفاع در عمق و محدودسازی دامنه اعتماد تناقض دارد. در نسخه های جدید ویندوز ، Credential Guard با جداسازی اسرار منتخب در محیط مبتنی بر مجازی‌سازی، این ضعف را کاهش می‌دهد. ❇️اختیار گسترده سرویس‌ها با LocalSystem: این حساب اختیارات بسیار بالایی دارد؛ بنابراین آسیب‌پذیری یک سرویس تحت آن می‌تواند پیامدی فراتر از همان سرویس ایجاد کند. از نگاه معماری، اجرای کاری محدود با چنین اختیاراتی، اصل حداقل اختیار و مهار دامنه خسارت را تضعیف می‌کند. خود مایکروسافت تصریح می‌کند بیشتر سرویس‌ها به این سطح اختیار نیاز ندارند. البته انتخاب LocalSystem برای سرویس‌های غیرضروری، غالباً تصمیم توسعه‌دهنده یا پیکربندی است؛ وجود این قابلیت به‌تنهایی نقض اصل محسوب نمی‌شود اما مطلبی قابل تامل است . ** مطالبی در باب آشنایی با دوره و مدرک ISSAP معماری ارشد امنیت اطلاعات

برترین های امنیت برای ایرانیان CISSP مدرک عالی امنیت ISSMP مدرک مدیریت ارشد امنیت ISSAP مدرک معمار ارشد امنیت نمره قبولی در آزمون ۱۲ آذر ماه CISSP حداقل ۷۰۰ از ۱۰۰۰ است اسپانسر: شرکت پیشگامان فناوری اطلاعات هامون

ویدئوی آموزشی من در صفحه لینکدین شرکت #هامون در مورد دزدی اطلاعات با ابزار های خودمان https://www.linkedin.com/posts/haumoun_aepaetaeuahyaes-cybersecurity-threatdetection-ugcPost-7512849075617173504-0OcV?utm_source=share&utm_medium=member_android&rcm=ACoAAAoOfTcB5k1E_hg69jDwmxkGWzsBxqx6B9s

آشنایی با ISSAP: اصول معماری امنیت و طرز فکر حرفه‌ای قسمت اول معماری امنیت، مجموعه‌ای از ابزارها، نمودارها یا فهرست کنترل‌ها نیست؛ بلکه رشته‌ای مبتنی بر تصمیم‌گیری ساختاریافته است که مشخص می‌کند قابلیت‌های امنیتی چگونه به‌صورت هدفمند طراحی شوند، با اهداف سازمان هم‌راستا گردند، تحت حاکمیت قرار گیرند و در سراسر سازمان پایدار بمانند. در سطح ISSAP، معمار دیگر صرفاً مسائل فنیِ جدا از یکدیگر را حل نمی‌کند؛ بلکه سیستم‌هایی را شکل می‌دهد که باید در برابر تغییرات دوام بیاورند، از اهداف کسب‌وکار پشتیبانی کنند، در مقابل تهدیدها مقاومت داشته باشند و در گذر زمان قابل راهبری و کنترل باقی بمانند. این فصل، مبانی مفهومی لازم برای اندیشیدن و فعالیت‌کردن به‌عنوان یک معمار امنیت حرفه‌ای را ارائه می‌کند. معماری امنیت به‌عنوان یک رشته حرفه‌ای معماری امنیت سازمانی در محل تلاقی راهبرد کسب‌وکار، مدیریت ریسک و پیاده‌سازی فنی قرار دارد. برخلاف نقش‌های عملیاتی امنیت که بر پیکربندی یا مدیریت کنترل‌ها تمرکز دارند، معماری امنیت ابتدا مشخص می‌کند امنیت باید به چه اهدافی برسد و چرا؛ سپس تعیین می‌کند این اهداف چگونه محقق شوند. مسئولیت معمار، تبدیل الزامات انتزاعی مانند محرمانگی، یکپارچگی، دسترس‌پذیری، تاب‌آوری، انطباق و اعتماد به ساختارهای معماری منسجمی است که پیاده‌سازی هماهنگ را هدایت کنند. معماری امنیت به‌عنوان یک رشته، بر هدف و منطق طراحی بیش از سازوکار اجرا تأکید می‌کند. فایروال‌ها، رمزنگاری، سامانه‌های هویت و سکوهای پایش، اجزای پیاده‌سازی هستند؛ معماری، روابط، مرزها، محدودیت‌ها و منطق تصمیم‌گیری را تعریف می‌کند که مشخص می‌سازند این اجزا چگونه در کنار یکدیگر عمل کنند. بدون معماری، امنیت واکنشی و پراکنده می‌شود. با معماری، امنیت هدفمند، تکرارپذیر و قابل دفاع خواهد بود. معماری امنیت همچنین نگاهی بلندمدت دارد. تصمیم‌هایی که در سطح معماری گرفته می‌شوند، بر سال‌ها تحول سیستم، انباشت بدهی فنی و میزان مواجهه با ریسک تأثیر می‌گذارند. به همین دلیل، این رشته به‌جای بهینه‌سازی کوتاه‌مدت، پایداری، سازگاری با تغییر و حاکمیت را در اولویت قرار می‌دهد ✨️اولین دوره ISSAP در ایران✨️ دوره معماری ارشد امنیت اطلاعات #آکادمی_روزبه 09902857290 ثبت نام #هامون

🕹دورهISSAP برای اولین بار در ایران

با توجه به نتایج فوق ، لازم است در مورد ISSAP آگاهی رسانی کنم

برداشتی از مقاله Pavel Yosifovich، از نویسندگان Windows Internals وقتی آنتی‌ویروس یا EDR می‌خواهد فعالیت‌های مشکوک را تشخیص دهد، باید بداند داخل ویندوز چه اتفاقی می‌افتد؛ مثلاً چه برنامه‌ای اجرا شده یا چه فایلی تغییر کرده است. بخشی از این اطلاعات در کرنل، یعنی هستهٔ ویندوز قرار دارد. محصولات امنیتی معمولاً برای دسترسی به این اطلاعات، درایور خود را داخل کرنل اجرا می‌کنند. مشکل اینجاست که خطای یک درایور می‌تواند کل ویندوز را متوقف کند و صفحهٔ آبی ایجاد شود؛ همان خطری که حادثهٔ CrowdStrike اهمیت آن را نشان داد. این مقاله، درایور جدید مایکروسافت به نام WESP را در یک نسخهٔ آزمایشی ویندوز بررسی می‌کند. ایده این است که یک مؤلفهٔ مایکروسافتی، اطلاعات امنیتی را از کرنل جمع‌آوری کند و به برنامه‌های امنیتی بیرون از کرنل برساند. این کار می‌تواند احتمال خرابی ویندوز بر اثر خطای محصولات امنیتی را کاهش دهد. نویسنده می‌پرسد: «این درایور چگونه اطلاعات را به برنامه‌ها می‌رساند؟» او بدون بررسی پیچیدهٔ کد، رجیستری، اشیای ویندوز و توابع استفاده‌شده در فایل‌ها را بررسی می‌کند. نتیجه این است که ارتباط از طریق Filter Communication Port انجام می‌شود؛ مثل یک کانال پیام‌رسانی میان هستهٔ ویندوز و برنامهٔ امنیتی. درس اصلی مقاله این است: برای فهمیدن عملکرد یک درایور، همیشه لازم نیست از خواندن کد شروع کنیم؛ سرنخ‌های اطراف آن هم اطلاعات ارزشمندی دارند. https://trainsec.net/library/windows-kernel/basic-reversing-of-a-windows-kernel-driver-how-wesp-talks-to-user-mode/

این هفته در کلاس CISSP یکی از دانشجویان پیشنهاد کرد که دوره ISSAP را برگزار کنم. این دوره در حوزه معماری و طراحی ارشد امنیت است و جزو سه مدرک برتر تخصصی بعد از CISSP است. شایان ذکر است تا کنون فقط ISSMP در حوزه مدیریت ارشد امنیت یکبار توسط من برگزار شده است. فارغ از اینکه درس ISSAP بسیار تخصصی و مفهومی است ، شناخت از آن در ایران بسیار پایین است. لذا فکر نمی‌کنم استقبال چندانی از این کلاس ارزشمند در ایران بشود. خصوصا در جامعه ای که با حجم بالای مهاجرت نخبگان مواجه است و متخصصان باقی مانده درگیر تورم لجام گسیخته به دنبال افزایش حقوق فعلی خود هستند. باز با خودم فکر کردم که یک نظر سنجی بگذارم اینکه بازخوردتون رو با من در میان می‌گذارید بسیار سپاسگذارم . #آکادمی_روزبه #هامون👇👇

تمرین های کلاسی دوره SOC T1 پنج شنبه ۹ مهر ماه ۱۴۰۵ مدرس جناب استاد حبیبی ، مدیر MSSP شرکت #هامون #آموزش #استخدام 09902857290

مقوله SOC as a Service؛ وقتی مرکز عملیات امنیت تبدیل به «سرویس» می‌شود بحث SOC as a Service (SOCaaS) مدلی است که در آن سازمان به‌جای ساخت و اداره کامل یک Security Operations Center در داخل مجموعه، بخشی یا تمام قابلیت‌های SOC را از یک ارائه‌دهنده تخصصی دریافت می‌کند. در این مدل، موضوع صرفاً خرید SIEM یا مانیتورینگ چند داشبورد نیست؛ بلکه مجموعه‌ای از People + Process + Technology به‌صورت یک سرویس مستمر ارائه می‌شود. یک SOCaaS بالغ معمولاً شامل جمع‌آوری و پایش Log و Telemetry، مدیریت SIEM، تحلیل Alert، Triage توسط L1، تحلیل عمیق‌تر توسط L2/L3، Threat Intelligence، Detection Engineering، Threat Hunting، مدیریت Use Caseها، گزارش‌دهی و Escalation است. بسته به قرارداد، Incident Response نیز می‌تواند بخشی از سرویس باشد. مزیت مهم SOCaaS، دسترسی سازمان به تیم متخصص بدون نیاز به ایجاد کامل یک SOC داخلی 24×7 است. هزینه جذب و نگهداری Analyst، Detection Engineer و Threat Hunter کاهش می‌یابد و ارائه‌دهنده می‌تواند تجربه حاصل از مشاهده محیط‌های متعدد را وارد عملیات کند. اما SOCaaS مساوی برون‌سپاری مسئولیت امنیت نیست. مالکیت Risk، تصمیمات حساس، پذیرش ریسک و Governance همچنان باید در سازمان باقی بماند. همچنین SLA، زمان تشخیص و Escalation، مالکیت داده، سطح دسترسی ارائه‌دهنده، Data Retention، محرمانگی و نحوه خروج از قرارداد باید دقیقاً مشخص شوند. از نظر معماری نیز SOCaaS الزاماً Cloud SOC نیست. SIEM و داده‌ها می‌توانند کاملاً On-Premise نزد مشتری باقی بمانند، در حالی که تیم MSSP از راه دور عملیات SOC را انجام دهد. بهترین نگاه به SOCaaS این است: ما «SOC ایجاد نمیکنیم ؛ قابلیت مستمر کشف، تحلیل و مدیریت تهدید را به‌عنوان سرویس دریافت می‌کنیم.» برای دریافت این سرویس با شرکت #هامون تماس حاصل فرمایید Www.haumoun.com #SOCaaS #SOC #MSSP #SIEM #DetectionEngineering #ThreatHunting #CyberSecurity #SecurityOperations #IncidentDetection #BlueTeam

ماتریس CLOAK Matrix؛ وقتی مهاجم تلاش می‌کند دیده نشود با تشکر از اشتراک گذاری جناب حمید مولایی ماتریس CLOAK Matrix یک چارچوب دانشی برای شناخت تکنیک‌های OPSEC و پنهان‌سازی مهاجمان سایبری است. اگر MITRE ATT&CK توضیح می‌دهد مهاجم برای نفوذ، حرکت جانبی، ماندگاری یا کنترل سیستم‌ها «چه کاری انجام می‌دهد»، CLOAK بیشتر بر این تمرکز دارد که مهاجم چگونه هویت، موقعیت، زیرساخت و ردپای خود را مخفی می‌کند. در این چارچوب تکنیک‌هایی مانند استفاده از Tor و VPN، Anonymous Hosting، Domain Fronting، Infrastructure Rotation، حذف Metadata، Anti-Forensics، پاک‌سازی ردپا، استفاده از هویت‌های مجزا و Compartmentalization بررسی می‌شوند. اهمیت CLOAK برای تیم‌های SOC و Threat Hunting در این است که تحلیلگر فقط به دنبال خود حمله نباشد، بلکه رفتارهایی را نیز جست‌وجو کند که برای کاهش قابلیت ردیابی و Attribution طراحی شده‌اند. بنابراین ترکیب MITRE ATT&CK + CLOAK دید کامل‌تری ایجاد می‌کند: ATT&CK رفتار عملیاتی مهاجم را نشان می‌دهد و CLOAK لایه پنهان‌سازی آن رفتار را آشکار می‌کند. برای Detection Engineering، این نگاه می‌تواند زمینه طراحی Detectionهای متفاوت و پیشرفته‌تری باشد. https://opsectechniques.com/

آیا مشاهده Sysmon Event ID 8 به‌تنهایی اثبات Process Injection است؟ خیر. مشاهده Sysmon Event ID 8 (CreateRemoteThread) نشانه‌ای مهم از رفتار مرتبط با Process Injection است، اما به‌تنهایی نمی‌تواند اثبات کند که تزریق مخرب رخ داده است. رویداد Event ID 8 زمانی ایجاد می‌شود که یک Process، Thread جدیدی را در فضای Process دیگری ایجاد کند. این تکنیک می‌تواند توسط بدافزارها برای اجرای کد در بستر پردازشی دیگر استفاده شود، اما برخی نرم‌افزارهای قانونی نیز ممکن است رفتار مشابهی داشته باشند. بنابراین در SOC باید آن را یک Signal بدانیم، نه یک Verdict. نبودن Event ID 10 (Process Access) نیز الزاماً Event 8 را بی‌اعتبار نمی‌کند. Event ID 10 وابسته به پیکربندی Sysmon و Filtering است و ممکن است دسترسی موردنظر ثبت نشده یا توسط Ruleهای پیکربندی حذف شده باشد. همچنین تله‌متری امنیتی همیشه تصویر کاملی از تمام مراحل یک رفتار ارائه نمی‌دهد. تحلیلگر بهتر است به جای جست‌وجوی یک Event خاص، زنجیره شواهد را بررسی کند. برای مثال: Event 1 → Event 10 → Event 8 → Network Activity اگر Event 10 وجود ندارد، باید سایر شواهد Event 8 بررسی شوند: SourceImage و TargetImage چه هستند؟ آیا Source Process از مسیر مشکوکی مانند Temp اجرا شده؟ StartAddress به کجا اشاره می‌کند؟ آیا StartModule یا StartFunction ناشناخته است؟ پس از ایجاد Thread، آیا Target Process رفتار شبکه‌ای یا فایل‌سیستمی غیرعادی نشان داده است؟ بنابراین Event ID 8 بدون Event ID 10 همچنان می‌تواند یک سرنخ بسیار مهم برای Process Injection باشد، اما نتیجه‌گیری نهایی باید بر اساس Context و Correlation انجام شود. این دقیقاً یکی از اصول مهم Detection Engineering است: یک Event به ما می‌گوید «چه اتفاقی افتاده»؛ اما مجموعه‌ای از Eventها و Context به ما کمک می‌کند بفهمیم «چرا اتفاق افتاده و آیا مخرب بوده است». دوره SOC آکادمی روزبه و شرکت هامون

شماره تماس برای دریافت مشاوره فنی سازمانها در حوزه امنیت سایبری با استاد روزبه CTO شرکت هامون 09902857290 لطفا پیام دهید با شما تماس گرفته خواهد شد 🙏

مقابله با شکستن پسورد به کمک ریاضیات توابع مشتق‌گیری کلید کُند (Slow KDFs) توابع مشتق‌گیری کلید کُند مانند Argon2id، bcrypt و PBKDF2، الگوریتم‌هایی هستند که عمداً با تحمیل بار محاسباتی و زمان‌بر بودن طراحی شده‌اند تا سرعت پردازش را مهار کنند. برخلاف توابع هش معمولی که بسیار سریع‌اند، KDFها با استفاده از هزاران چرخه تکرار (Iterations) و در نمونه‌های مدرن نظیر Argon2 با درگیر کردن حجم مشخصی از حافظه رم (Memory-Hardness)، هزینه محاسبات را به شدت بالا می‌برند. این ویژگی کُندی کنترل‌شده، حملات Brute-Force را تقریبا خنثی کرده و استفاده از پردازنده‌های گرافیکی (GPU) یا تجهیزات اختصاصی (ASIC) برای شکستن انبوه پسوردها را غیراقتصادی می‌سازد. #زیبایی_ریاضی #آکادمی_روزبه دوره 82 ام CISSP از دیماه فرصت استفاده از 30 درصد تخفیف تا ۱۵ مهر 09902857290

مقوله DevSecOps؛ امنیت به‌عنوان بخشی از فرایند توسعه بحث DevSecOps رویکردی است که امنیت را از یک کنترل نهایی، به مسئولیتی مشترک در سراسر چرخه توسعه نرم‌افزار تبدیل می‌کند. در روش سنتی، تیم امنیت معمولاً پس از تکمیل محصول وارد عمل می‌شود؛ زمانی که اصلاح آسیب‌پذیری‌ها پرهزینه، دشوار و گاهی غیرممکن است. در DevSecOps، کنترل‌های امنیتی از مرحله طراحی و کدنویسی آغاز می‌شوند و تا استقرار و بهره‌برداری ادامه می‌یابند. در این رویکرد، Pipeline می‌تواند به‌صورت خودکار کد، کتابخانه‌ها، Container Image، تنظیمات زیرساخت و Secretها را ارزیابی کند. ابزارهایی مانند SAST، DAST، SCA، IaC Scanning و Secret Scanning به شناسایی زودهنگام ضعف‌ها کمک می‌کنند؛ اما DevSecOps صرفاً مجموعه‌ای از ابزارها نیست. فرهنگ همکاری میان توسعه‌دهندگان، تیم عملیات و متخصصان امنیت، هسته اصلی آن را تشکیل می‌دهد. یکی از نقاط حساس، اجرای کد متعلق به Pull Requestهای تأییدنشده است. چنین کدی نباید در محیطی اجرا شود که به Token، Cloud Credential، Registry یا Runnerهای عملیاتی دسترسی دارد. تفکیک Pipelineهای غیرقابل‌اعتماد، اعمال Least Privilege، استفاده از Runnerهای موقت و فعال‌سازی Approval پیش از Deployment از کنترل‌های ضروری هستند. هدف DevSecOps متوقف‌کردن توسعه نیست؛ بلکه تولید نرم‌افزار امن‌تر با سرعتی پایدار است. امنیت زمانی مؤثر خواهد بود که در معماری، کد، Pipeline و عملیات روزانه حضور داشته باشد، نه اینکه فقط پیش از انتشار بررسی شود. #DevSecOps #DevOps #CyberSecurity #ApplicationSecurity #SecureCoding #SoftwareSecurity #CICD #SecurityAutomation #ShiftLeftSecurity #CloudSecurity #PipelineSecurity #SupplyChainSecurity #SAST #DAST #SCA #امنیت_سایبری #امنیت_نرم_افزار #توسعه_امن #مهندسی_امنیت #آکادمی_روزبه

یادگیری چه زمانی عمیق میشود؟ یادگیری زمانی عمیق می‌شود که اطلاعات را فقط «بخوانیم» یا «بشنویم»، بلکه بتوانیم آن را توضیح دهیم، اجرا کنیم، نقد کنیم و در موقعیتی تازه به کار ببریم. برای عمیق‌کردن یادگیری، این چرخه بسیار مؤثر است: 1. فهم مفهومی بعد از مطالعه بپرسید: «این موضوع چرا وجود دارد و چه مسئله‌ای را حل می‌کند؟» برای مثال در DevSecOps، فقط ابزارهای SAST را حفظ نکنید؛ بفهمید چرا کشف ضعف در ابتدای توسعه کم‌هزینه‌تر است. 2. بازگویی بدون منبع کتاب را ببندید و مطلب را با زبان ساده توضیح دهید. اگر نتوانستید آن را برای فردی مبتدی تشریح کنید، هنوز کاملاً نفهمیده‌اید. 3. بازیابی فعال به‌جای چند بار خواندن، از خودتان سؤال بپرسید. آزمون، فلش‌کارت و سناریوهای CISSP دقیقاً به همین دلیل از مرور منفعل مؤثرترند. 4. تمرین عملی مفهوم باید به تجربه تبدیل شود. در آموزش SOC، دانشجو باید PCAP تحلیل کند، Alert بسازد، Logها را Correlate کند و درباره Incident تصمیم بگیرد. 5. تحلیل خطا فقط پاسخ درست را بررسی نکنید؛ بنویسید چرا پاسخ شما اشتباه بود: ضعف دانش، برداشت نادرست، عجله یا ناتوانی در تحلیل سناریو؟ 6. اتصال مفاهیم مطالب جدید را به دانش قبلی متصل کنید. مثلاً رابطه میان Credential Access، حرکت جانبی، Logهای ویندوز و Detection Engineering را در قالب یک Attack Chain ببینید. 7. مرور فاصله‌دار مرور را در فاصله‌های یک روز، یک هفته و یک ماه انجام دهید. یادگیری فشرده ممکن است برای امتحان کافی باشد، اما یادگیری پایدار نیازمند بازگشت هدفمند است.

آنچه که بعنوان MZ در امنیت گفته میشود چیست و چرا در تحلیل بدافزار اهمیت دارد؟ عبارت "MZ" دو بایت ابتدایی بسیاری از فایل‌های اجرایی ویندوز است و در مبنای هگزادسیمال به‌صورت "4D 5A" نمایش داده می‌شود. این حروف از نام Mark Zbikowski، یکی از مهندسان مایکروسافت و طراح قالب اجرایی DOS، گرفته شده‌اند. فایل‌های اجرایی با ساختار PE، مانند فایل‌های "EXE"، "DLL"، "SYS" و برخی "SCR"ها، معمولاً با امضای MZ آغاز می‌شوند. بخش ابتدایی فایل، "DOS Header" نام دارد. درون این Header، فیلدی به نام "e_lfanew" وجود دارد که محل قرارگیری امضای "PE" و ساختار اصلی فایل اجرایی ویندوز را مشخص می‌کند. اهمیت MZ زمانی آشکار می‌شود که مهاجم پسوند واقعی فایل را پنهان کرده باشد. برای مثال ممکن است فایلی با نام "update.dat"، "invoice.jpg" یا "document.pdf" دریافت شود، اما بررسی محتوای آن نشان دهد که دو بایت ابتدایی فایل "MZ" است. این وضعیت نشان می‌دهد فایل احتمالاً یک برنامه اجرایی ویندوز است، نه تصویر یا سند معمولی. در تحلیل PCAP می‌توان فایل منتقل‌شده را از جریان HTTP یا SMB استخراج و Header آن را بررسی کرد. بااین‌حال، مشاهده MZ به‌تنهایی اثبات بدافزاربودن فایل نیست؛ زیرا برنامه‌های سالم ویندوز نیز همین امضا را دارند. تحلیلگر باید Hash، امضای دیجیتال، Importها، رشته‌ها، رفتار اجرایی و نتایج Sandbox را نیز بررسی کند. #MZ #PEFile #PortableExecutable #MalwareAnalysis #DigitalForensics #MemoryForensics #NetworkForensics #PCAP #Wireshark #ThreatHunting #IncidentResponse #ReverseEngineering #SOC #CyberSecurity #تحلیل_بدافزار #فارنزیک_دیجیتال #تحلیل_ترافیک #امنیت_سایبری #مرکز_عملیات_امنیت #آکادمی_روزبه

4️⃣مقاله چهارم و پایان : CiliumHound چگونه مسیرهای حمله را آشکار می‌کند؟ در یک Cluster بزرگ، بررسی دستی فایل‌های Network Policy نمی‌تواند به‌سادگی نشان دهد که پس از تسخیر یک Pod چه مسیرهایی در اختیار مهاجم قرار می‌گیرد. این CiliumHound اطلاعات Kubernetes و سیاست‌های شبکه Cilium را جمع‌آوری و در قالب BloodHound OpenGraph نمایش می‌دهد. در این گراف، اجزایی مانند Workloadها و Namespaceها به‌صورت Node و دسترسی‌های میان آن‌ها به‌صورت Edge دیده می‌شوند. فرض کنید Web Pod اجازه ارتباط با API Pod را دارد و API نیز می‌تواند به Database و Admin Service متصل شود. مهاجمی که Web Pod را تصرف کرده است، شاید مستقیماً به پایگاه‌داده دسترسی نداشته باشد؛ اما گراف مسیر زیر را آشکار می‌کند: Web Pod → API Pod → Database این زنجیره یک Attack Path است. CiliumHound کمک می‌کند سیاست‌های بیش‌ازحد باز، ارتباطات ناخواسته میان Namespaceها و مسیرهای احتمالی حرکت جانبی شناسایی شوند. تفاوت مهم آن با Hubble این است که Hubble ترافیک مشاهده‌شده را نمایش می‌دهد، اما CiliumHound روی مسیرهایی تمرکز دارد که براساس Policyها امکان‌پذیرند؛ حتی اگر هنوز استفاده نشده باشند. این CiliumHound جلوی حمله را نمی‌گیرد؛ بلکه نشان می‌دهد طراحی Microsegmentation کجا ممکن است برای مهاجم یک مسیر پنهان ساخته باشد. #Kubernetes #KubernetesSecurity #Cilium #CiliumHound #BloodHound #OpenGraph #NetworkPolicy #Microsegmentation #eBPF #ContainerSecurity #CloudNativeSecurity #AttackPath #LateralMovement #ZeroTrust #DevSecOps #CyberSecurity #امنیت_کوبرنتیز #امنیت_کانتینر #ریزتقسیم‌بندی #مسیر_حمله #حرکت_جانبی #امنیت_ابری #امنیت_سایبری #مهندسی_کشف