آشنایی با واژه

کلمه Dedication را می‌توان «تعهد عمیق و پایدار به یک هدف» ترجمه کرد؛ یعنی انسان حتی وقتی هیجان اولیه از بین رفته، نتیجه هنوز دیده نمی‌شود یا مسیر دشوار شده است، همچنان به انجام کارهای ضروری ادامه دهد.

فرد متعهد نمی‌گوید: «اگر انگیزه داشتم، کار می‌کنم.»
می‌گوید: «چون این هدف برایم مهم است، امروز سهم خودم را انجام می‌دهم.»

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

نمونه‌هایی از تاریخ

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

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

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

نلسون ماندلا ۲۷ سال زندان را تحمل کرد، اما هدف خود برای پایان‌دادن به آپارتاید را رها نکرد. آنچه او را ماندگار کرد، فقط مقاومت نبود؛ توانایی حفظ هدف، کنترل خشم و تبدیل رنج شخصی به یک حرکت سیاسی سازنده بود.

برای استخدام و حقوق مکفی ، باید تعهد به هدف داشته باشید

1⃣سلسله مقالات کوبرنتیز تا CiliumHound

مقاله اول: Kubernetes چیست و چرا به آن نیاز داریم؟

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

هر سرویس معمولاً داخل یک Container اجرا می‌شود. اما وقتی تعداد Containerها به صدها یا هزاران مورد برسد، مدیریت آن‌ها دشوار خواهد شد. Kubernetes سامانه‌ای است که استقرار، اجرا، مقیاس‌دهی و بازیابی خودکار این Containerها را مدیریت می‌کند.

کوچک‌ترین واحد اجرایی در Kubernetes معمولاً Pod نام دارد. یک یا چند Pod می‌توانند یک برنامه را ارائه کنند. Podها روی ماشین‌هایی به نام Node اجرا می‌شوند و مجموعه Nodeها یک Cluster را تشکیل می‌دهد. Service نیز یک آدرس نسبتاً ثابت برای دسترسی به گروهی از Podها فراهم می‌کند.

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

بااین‌حال، Kubernetes فقط یک بستر اجرایی نیست؛ بلکه محیطی پویا با ارتباطات فراوان است. Podها دائماً ایجاد، حذف و جابه‌جا می‌شوند. بنابراین کنترل اینکه هر Pod با چه بخش‌هایی ارتباط دارد، به یکی از مهم‌ترین مسائل امنیتی Kubernetes تبدیل می‌شود.


ادامه دارد ....👇👇

2⃣مقاله دوم: ارتباط Podها و خطر حرکت جانبی در Kubernetes

در Kubernetes، اجزای مختلف یک برنامه باید با یکدیگر ارتباط داشته باشند. برای مثال، Web Pod درخواست کاربر را دریافت می‌کند، آن را به API Pod می‌فرستد و API نیز برای بازیابی اطلاعات به Database Pod متصل می‌شود.

این ارتباطات برای عملکرد برنامه ضروری‌اند؛ اما اگر کنترل نشوند، مسیر حمله ایجاد می‌کنند. فرض کنید Web Pod دارای آسیب‌پذیری باشد و مهاجم کنترل آن را به دست آورد. اگر محدودیت شبکه‌ای مناسبی وجود نداشته باشد، مهاجم می‌تواند از همان Pod به پایگاه‌داده، پنل مدیریتی یا دیگر سرویس‌های داخلی متصل شود. این جابه‌جایی از نقطه اولیه نفوذ به بخش‌های دیگر، Lateral Movement نام دارد.

برای جلوگیری از این وضعیت، Kubernetes مفهومی به نام Network Policy دارد. این سیاست مشخص می‌کند کدام Pod اجازه دارد با چه مقصدی و روی چه Port یا Protocol ارتباط برقرار کند.

مثلاً می‌توان تعیین کرد Web Pod فقط به API و API فقط به Database دسترسی داشته باشد. همچنین می‌توان ارتباط مستقیم Web با Database را مسدود کرد.

مسئله این است که در یک Cluster واقعی صدها Pod، ده‌ها Namespace و تعداد زیادی Policy وجود دارد. در چنین محیطی، حتی اگر همه‌چیز روی کاغذ امن به نظر برسد، ترکیب چند مجوز کوچک ممکن است یک مسیر خطرناک بسازد. بنابراین صرفاً داشتن Network Policy کافی نیست؛ باید اثر نهایی همه سیاست‌ها را نیز مشاهده و ارزیابی کنیم.


ادامه دارد ....👇👇

3️⃣مقاله سوم: Cilium چگونه ارتباطات Kubernetes را کنترل می‌کند؟

این Kubernetes برای مدیریت ارتباطات شبکه‌ای به یک افزونه شبکه یا CNI نیاز دارد. Cilium یکی از پیشرفته‌ترین راهکارهای این حوزه است که با استفاده از فناوری eBPF، ارتباطات میان Podها، Nodeها و سرویس‌ها را کنترل و مشاهده می‌کند.

وCilium می‌تواند Network Policyهای استاندارد Kubernetes و سیاست‌های پیشرفته‌تری مانند CiliumNetworkPolicy را اجرا کند. این سیاست‌ها تعیین می‌کنند چه مبدأیی اجازه دارد به چه مقصدی، روی کدام Port و Protocol متصل شود. در موارد پیشرفته‌تر، کنترل ارتباطات تا لایه کاربرد و پروتکل‌هایی مانند HTTP و DNS نیز امکان‌پذیر است.

وCilium معمولاً Podها را براساس Label و Security Identity شناسایی می‌کند. برای مثال، به‌جای وابستگی به IP متغیر یک Pod، می‌توان گفت هر Pod دارای Label برابر "frontend" فقط به Podهای "api" دسترسی داشته باشد.

این انعطاف بسیار ارزشمند است، اما پیچیدگی نیز ایجاد می‌کند. ممکن است یک Policy دسترسی را محدود و Policy دیگری همان ارتباط را از مسیر متفاوتی مجاز کند. همچنین تغییر Label یا اضافه‌شدن یک Workload جدید می‌تواند نتیجه نهایی را تغییر دهد.

ابزار Hubble در اکوسیستم Cilium نشان می‌دهد چه ترافیکی واقعاً میان اجزای Cluster ردوبدل شده است. بااین‌حال، مشاهده ترافیک گذشته همیشه پاسخ نمی‌دهد که براساس Policyها چه ارتباطاتی بالقوه مجازند. برای پاسخ به این سؤال باید روابط مجاز را مانند یک نقشه جامع تحلیل کنیم؛ نیازی که زمینه استفاده از CiliumHound را ایجاد می‌کند.

ادامه دارد ....👇👇

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 #امنیت_کوبرنتیز #امنیت_کانتینر #ریزتقسیم‌بندی #مسیر_حمله #حرکت_جانبی #امنیت_ابری #امنیت_سایبری #مهندسی_کشف

آنچه که بعنوان 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 #تحلیل_بدافزار #فارنزیک_دیجیتال #تحلیل_ترافیک #امنیت_سایبری #مرکز_عملیات_امنیت #آکادمی_روزبه

یادگیری چه زمانی عمیق میشود؟

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

برای عمیق‌کردن یادگیری، این چرخه بسیار مؤثر است:

1. فهم مفهومی

بعد از مطالعه بپرسید: «این موضوع چرا وجود دارد و چه مسئله‌ای را حل می‌کند؟» برای مثال در DevSecOps، فقط ابزارهای SAST را حفظ نکنید؛ بفهمید چرا کشف ضعف در ابتدای توسعه کم‌هزینه‌تر است.

2. بازگویی بدون منبع

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

3. بازیابی فعال

به‌جای چند بار خواندن، از خودتان سؤال بپرسید. آزمون، فلش‌کارت و سناریوهای CISSP دقیقاً به همین دلیل از مرور منفعل مؤثرترند.

4. تمرین عملی

مفهوم باید به تجربه تبدیل شود. در آموزش SOC، دانشجو باید PCAP تحلیل کند، Alert بسازد، Logها را Correlate کند و درباره Incident تصمیم بگیرد.

5. تحلیل خطا

فقط پاسخ درست را بررسی نکنید؛ بنویسید چرا پاسخ شما اشتباه بود: ضعف دانش، برداشت نادرست، عجله یا ناتوانی در تحلیل سناریو؟

6. اتصال مفاهیم

مطالب جدید را به دانش قبلی متصل کنید. مثلاً رابطه میان Credential Access، حرکت جانبی، Logهای ویندوز و Detection Engineering را در قالب یک Attack Chain ببینید.

7. مرور فاصله‌دار

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

مقوله 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 #امنیت_سایبری #امنیت_نرم_افزار #توسعه_امن #مهندسی_امنیت #آکادمی_روزبه

مقابله با شکستن پسورد به کمک ریاضیات
توابع مشتق‌گیری کلید کُند (Slow KDFs)

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


#زیبایی_ریاضی
#آکادمی_روزبه

دوره 82 ام CISSP از دیماه
فرصت استفاده از 30 درصد تخفیف تا ۱۵ مهر
09902857290

شماره تماس برای دریافت مشاوره فنی سازمانها در حوزه امنیت سایبری با استاد روزبه CTO شرکت هامون

09902857290
لطفا پیام دهید با شما تماس گرفته خواهد شد 🙏

آیا مشاهده 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 آکادمی روزبه و شرکت هامون

ماتریس 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/

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

این هفته در کلاس CISSP یکی از دانشجویان پیشنهاد کرد که دوره ISSAP را برگزار کنم.
این دوره در حوزه معماری و طراحی ارشد امنیت است و جزو سه مدرک برتر تخصصی بعد از CISSP است.
شایان ذکر است تا کنون فقط ISSMP در حوزه مدیریت ارشد امنیت یکبار توسط من برگزار شده است.

فارغ از اینکه درس 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/