هانت با Velociraptor
این هفته تدریس هانت و فارنزیک در یکی از سازمانهای کشور را شروع کردم.
دریکی از جلسات هانت با Velociraptor در برنامه است. یکی از قابلیتهای ارزشمند Velociraptor در عملیات Threat Hunting و DFIR، امکان اجرای YARA روی حافظه Processها است؛ قابلیتی که به تحلیلگران اجازه میدهد حملات Fileless و اجرای کد در RAM را شناسایی کنند.
در یکی از سناریوهای عملیاتی، از یک Rule ساده YARA برای جستجوی رشتههایی مانند Invoke-Mimikatz و DownloadString در حافظه Processها استفاده میشود.
rule Suspicious_PS
{
strings:
$a = "Invoke-Mimikatz" nocase wide ascii
$b = "DownloadString" nocase wide ascii
condition:
any of them
}
این رشتهها معمولاً با PowerShell-based attack و ابزارهای Post-Exploitation مرتبط هستند. Velociraptor با استفاده از Artifactهایی مانند Windows.Detection.Yara.Process حافظه Processهای فعال را بهصورت Remote اسکن کرده و وجود این الگوها را شناسایی میکند.
نتیجه این Hunt نشان میدهد که حتی در شرایطی که فایل مخربی روی Disk وجود ندارد و مهاجم از تکنیکهای Fileless استفاده میکند، همچنان میتوان آثار اجرای حمله را در Memory مشاهده کرد. این موضوع اهمیت Memory Hunting را در کشف تهدیدات مدرن نشان میدهد؛ جایی که تحلیل صرف فایلها و آنتیویروسهای سنتی ممکن است ناکافی باشند. Velociraptor با ترکیب YARA، Threat Hunting و DFIR، دید عمیقتری از رفتار واقعی مهاجم در Endpoint فراهم میکند.
این هفته تدریس هانت و فارنزیک در یکی از سازمانهای کشور را شروع کردم.
دریکی از جلسات هانت با Velociraptor در برنامه است. یکی از قابلیتهای ارزشمند Velociraptor در عملیات Threat Hunting و DFIR، امکان اجرای YARA روی حافظه Processها است؛ قابلیتی که به تحلیلگران اجازه میدهد حملات Fileless و اجرای کد در RAM را شناسایی کنند.
در یکی از سناریوهای عملیاتی، از یک Rule ساده YARA برای جستجوی رشتههایی مانند Invoke-Mimikatz و DownloadString در حافظه Processها استفاده میشود.
rule Suspicious_PS
{
strings:
$a = "Invoke-Mimikatz" nocase wide ascii
$b = "DownloadString" nocase wide ascii
condition:
any of them
}
این رشتهها معمولاً با PowerShell-based attack و ابزارهای Post-Exploitation مرتبط هستند. Velociraptor با استفاده از Artifactهایی مانند Windows.Detection.Yara.Process حافظه Processهای فعال را بهصورت Remote اسکن کرده و وجود این الگوها را شناسایی میکند.
نتیجه این Hunt نشان میدهد که حتی در شرایطی که فایل مخربی روی Disk وجود ندارد و مهاجم از تکنیکهای Fileless استفاده میکند، همچنان میتوان آثار اجرای حمله را در Memory مشاهده کرد. این موضوع اهمیت Memory Hunting را در کشف تهدیدات مدرن نشان میدهد؛ جایی که تحلیل صرف فایلها و آنتیویروسهای سنتی ممکن است ناکافی باشند. Velociraptor با ترکیب YARA، Threat Hunting و DFIR، دید عمیقتری از رفتار واقعی مهاجم در Endpoint فراهم میکند.
❤8
آیا ضعف در آموزش ریاضی بر کیفیت متخصصان امنیت سایبری اثر میگذارد؟
وقتی درباره امنیت سایبری صحبت میشود، بسیاری تصور میکنند مهمترین مهارتها شامل کار با ابزارها، شناخت حملات یا یادگیری فناوریهای جدید است. اما در عمل، یکی از عوامل پنهان و بسیار اثرگذار در کیفیت متخصصان امنیت، نوع تفکری است که سیستم آموزشی در افراد ایجاد میکند؛ و آموزش ریاضی در این میان نقش مهمی دارد.
موضوع فقط رمزنگاری یا فرمولهای پیچیده نیست. حتی اگر بخش Cryptography را کنار بگذاریم، امنیت سایبری همچنان به تفکر تحلیلی، مدلسازی ذهنی و توانایی کشف الگو وابسته است. یک تحلیلگر SOC حرفهای باید بتواند میان هزاران لاگ و Event، ارتباطهای غیرآشکار را تشخیص دهد و از دل رفتارهای ظاهراً عادی، نشانههای حمله را استخراج کند. این فرآیند بیشتر شبیه تحلیل سیستم و استدلال منطقی است تا صرفاً کار با ابزارها.
آموزش ریاضی قوی معمولاً مهارتهایی مانند تفکر ساختاریافته، تحلیل علت و معلول، abstraction و reasoning را تقویت میکند؛ مهارتهایی که در Threat Hunting، Detection Engineering و DFIR بسیار حیاتیاند. در مقابل، ضعف در این حوزه میتواند باعث شود بخشی از نیروها بیش از حد ابزارمحور شوند و در تحلیل عمیق، طراحی Detection Logic یا تفکر adversarial ضعف داشته باشند.
به همین دلیل، بسیاری از متخصصان برجسته امنیت الزاماً کسانی نیستند که فقط مدارک متعدد دارند؛ بلکه افرادی هستند که قدرت تحلیل سیستمی و ذهن ساختاریافتهتری دارند. امنیت سایبری بیش از آنکه صرفاً یک مهارت فنی باشد، یک شیوه تفکر تحلیلی است؛ و آموزش ریاضی میتواند یکی از پایههای شکلگیری این ذهنیت باشد.
وقتی درباره امنیت سایبری صحبت میشود، بسیاری تصور میکنند مهمترین مهارتها شامل کار با ابزارها، شناخت حملات یا یادگیری فناوریهای جدید است. اما در عمل، یکی از عوامل پنهان و بسیار اثرگذار در کیفیت متخصصان امنیت، نوع تفکری است که سیستم آموزشی در افراد ایجاد میکند؛ و آموزش ریاضی در این میان نقش مهمی دارد.
موضوع فقط رمزنگاری یا فرمولهای پیچیده نیست. حتی اگر بخش Cryptography را کنار بگذاریم، امنیت سایبری همچنان به تفکر تحلیلی، مدلسازی ذهنی و توانایی کشف الگو وابسته است. یک تحلیلگر SOC حرفهای باید بتواند میان هزاران لاگ و Event، ارتباطهای غیرآشکار را تشخیص دهد و از دل رفتارهای ظاهراً عادی، نشانههای حمله را استخراج کند. این فرآیند بیشتر شبیه تحلیل سیستم و استدلال منطقی است تا صرفاً کار با ابزارها.
آموزش ریاضی قوی معمولاً مهارتهایی مانند تفکر ساختاریافته، تحلیل علت و معلول، abstraction و reasoning را تقویت میکند؛ مهارتهایی که در Threat Hunting، Detection Engineering و DFIR بسیار حیاتیاند. در مقابل، ضعف در این حوزه میتواند باعث شود بخشی از نیروها بیش از حد ابزارمحور شوند و در تحلیل عمیق، طراحی Detection Logic یا تفکر adversarial ضعف داشته باشند.
به همین دلیل، بسیاری از متخصصان برجسته امنیت الزاماً کسانی نیستند که فقط مدارک متعدد دارند؛ بلکه افرادی هستند که قدرت تحلیل سیستمی و ذهن ساختاریافتهتری دارند. امنیت سایبری بیش از آنکه صرفاً یک مهارت فنی باشد، یک شیوه تفکر تحلیلی است؛ و آموزش ریاضی میتواند یکی از پایههای شکلگیری این ذهنیت باشد.
❤5
چرا در مورد فورتی وب مینویسم ؟
آره کار من با فورتی وب به حدود ۱۳ تا ۱۰ سال پیش برمیگرده ؛ از نصب تا تیونینگ و بررسی لاگ.
اما چیزی که این روزها دغدغه من شده ، کانفیگ نامناسب برای تعداد بالای وف هایی هست که میبینم. لذا کشف و مقابله درستی نداریم و دیتا سورس SOC های ما هم ناکامله.
دوستان
وف قرار هست حملات رو کشف کنه و مقابله ، لاگش هم در SOC خیلی حیاتیه
اما
ما با عدم تنظیم مناسب ، اونو از یه بنز به پراید تقلیل دادیم !!
این روزها وف هایی میبینم که باید به حال مالکان اونها ناراحت شد . اونچه من میبینم اینه که تنظیمات وف به یه عنصر لاکچری در کشور بدل شده درحالیکه یکی از اقلام ضروری کالابرگ!! سازمانیه
لذا
یه دپارتمان در شرکت هامون تشکیل دادم که یکی از کاراش فقط تیونینگ وف هست. پس یکی از اقلام کاتالوگ خدمات شرکت هامون شده "ارتقای عملیاتی وف"
اینجوری هم کنترل مهمی چون وف درست در مدار هست هم SOC شما میتونه یه قدم ارتقا پیدا کنه
لذا کمکی لازم بود با واحد فروش شرکت هامون در تماس باشید .
#خدمت_اختصاصی
آره کار من با فورتی وب به حدود ۱۳ تا ۱۰ سال پیش برمیگرده ؛ از نصب تا تیونینگ و بررسی لاگ.
اما چیزی که این روزها دغدغه من شده ، کانفیگ نامناسب برای تعداد بالای وف هایی هست که میبینم. لذا کشف و مقابله درستی نداریم و دیتا سورس SOC های ما هم ناکامله.
دوستان
وف قرار هست حملات رو کشف کنه و مقابله ، لاگش هم در SOC خیلی حیاتیه
اما
ما با عدم تنظیم مناسب ، اونو از یه بنز به پراید تقلیل دادیم !!
این روزها وف هایی میبینم که باید به حال مالکان اونها ناراحت شد . اونچه من میبینم اینه که تنظیمات وف به یه عنصر لاکچری در کشور بدل شده درحالیکه یکی از اقلام ضروری کالابرگ!! سازمانیه
لذا
یه دپارتمان در شرکت هامون تشکیل دادم که یکی از کاراش فقط تیونینگ وف هست. پس یکی از اقلام کاتالوگ خدمات شرکت هامون شده "ارتقای عملیاتی وف"
اینجوری هم کنترل مهمی چون وف درست در مدار هست هم SOC شما میتونه یه قدم ارتقا پیدا کنه
لذا کمکی لازم بود با واحد فروش شرکت هامون در تماس باشید .
#خدمت_اختصاصی
❤3
وبینار عوامل موثر بر ارتقای کشف و بهروری در SOC های موجود - تجربه ی زیسته
اطلاعات بیشتر را در بخش توضیحات لینک زیر بخوانید
https://eseminar.tv/wb176454
دوشنبه 4 خرداد ماه در ایسمینار ساعت 20
ثبت نام زود هنگام با 40 درصد تخفیف
اطلاعات بیشتر را در بخش توضیحات لینک زیر بخوانید
https://eseminar.tv/wb176454
دوشنبه 4 خرداد ماه در ایسمینار ساعت 20
ثبت نام زود هنگام با 40 درصد تخفیف
❤3
شهود انسانی در برابر سرعت هوش مصنوعی؛ آینده جدید Threat Hunting
مقوله Threat Hunting مدرن وارد مرحلهای جدید و پیچیده شده است. سالها، موفقترین عملیاتهای هانت وابسته به تجربه، شهود و درک انسانی تحلیلگران بود. یک Threat Hunter حرفهای میتوانست رفتارهای غیرعادی مهاجم را از میان حجم عظیمی از دادهها تشخیص دهد، سیگنالهای ضعیف را به هم متصل کند و فرضیات اشتباه را به چالش بکشد. به همین دلیل هنوز بسیاری معتقدند که «Threat Hunting ذاتاً انسانمحور است.»
اما ظهور تهدیدات مبتنی بر هوش مصنوعی، معادله را تغییر داده است. مهاجمان اکنون میتوانند با سرعت ماشین، عملیات Reconnaissance، فیشینگ، تولید بدافزار، تحلیل هدف و حتی حملات تطبیقی انجام دهند. در چنین شرایطی، مدلهای سنتی هانت که کاملاً متکی به انسان هستند، دیگر سرعت کافی ندارند. اینجاست که یک سؤال مهم مطرح میشود: چگونه میتوان عمق تحلیل انسانی را با سرعت AI ترکیب کرد؟
پاسخ در حذف انسان نیست، بلکه در تقویت اوست. هوش مصنوعی میتواند تحلیل حجم عظیم telemetry، correlation، anomaly detection و triage اولیه را انجام دهد، در حالی که تحلیلگر انسانی روی hypothesis building، تفسیر رفتار مهاجم و تصمیمگیری نهایی تمرکز میکند.
آینده Threat Hunting نه کاملاً انسانی خواهد بود و نه کاملاً خودکار؛ بلکه متعلق به تیمهایی است که بتوانند قضاوت انسانی را با سرعت پردازش AI ترکیب کنند.
مقوله Threat Hunting مدرن وارد مرحلهای جدید و پیچیده شده است. سالها، موفقترین عملیاتهای هانت وابسته به تجربه، شهود و درک انسانی تحلیلگران بود. یک Threat Hunter حرفهای میتوانست رفتارهای غیرعادی مهاجم را از میان حجم عظیمی از دادهها تشخیص دهد، سیگنالهای ضعیف را به هم متصل کند و فرضیات اشتباه را به چالش بکشد. به همین دلیل هنوز بسیاری معتقدند که «Threat Hunting ذاتاً انسانمحور است.»
اما ظهور تهدیدات مبتنی بر هوش مصنوعی، معادله را تغییر داده است. مهاجمان اکنون میتوانند با سرعت ماشین، عملیات Reconnaissance، فیشینگ، تولید بدافزار، تحلیل هدف و حتی حملات تطبیقی انجام دهند. در چنین شرایطی، مدلهای سنتی هانت که کاملاً متکی به انسان هستند، دیگر سرعت کافی ندارند. اینجاست که یک سؤال مهم مطرح میشود: چگونه میتوان عمق تحلیل انسانی را با سرعت AI ترکیب کرد؟
پاسخ در حذف انسان نیست، بلکه در تقویت اوست. هوش مصنوعی میتواند تحلیل حجم عظیم telemetry، correlation، anomaly detection و triage اولیه را انجام دهد، در حالی که تحلیلگر انسانی روی hypothesis building، تفسیر رفتار مهاجم و تصمیمگیری نهایی تمرکز میکند.
آینده Threat Hunting نه کاملاً انسانی خواهد بود و نه کاملاً خودکار؛ بلکه متعلق به تیمهایی است که بتوانند قضاوت انسانی را با سرعت پردازش AI ترکیب کنند.
❤5
اگر همه چیز فانی است ، چرا تلاش کنیم ؟!
آیهٔ «كُلُّ مَنْ عَلَيْهَا فَانٍ» از سوره الرحمن، یکی از عمیقترین آیات قرآن درباره ناپایداری جهان است. این آیه یادآوری میکند که همه چیز در دنیا ، انسانها، قدرت، ثروت و حتی تمدنها ، روزی از بین میروند و تنها حقیقت پایدار، ذات الهی است. در نگاه عرفانی، این آیه فقط درباره مرگ نیست؛ بلکه درباره فانی بودن غرور، تعلقات و هویتهای ظاهری انسان نیز سخن میگوید. پیام اصلی آیه این است که انسان نباید تمام وجود خود را به چیزهای موقتی گره بزند، بلکه باید به دنبال معنا، آگاهی، عشق و ارزشهای عمیقتر در زندگی باشد.
اگر ما این موضوع را درک کنیم ، از بسیاری حسادت ها ، تعلقات ، تکبر ها، دروغ ها و تلاش های ظاهری کاسته میشود و ما "انسان" میشویم.
در ویرگول بیشتر صحبت کرده ام که اگر فانی هستیم چرا باید تلاش کنیم ؟
https://vrgl.ir/jYTXy
آیهٔ «كُلُّ مَنْ عَلَيْهَا فَانٍ» از سوره الرحمن، یکی از عمیقترین آیات قرآن درباره ناپایداری جهان است. این آیه یادآوری میکند که همه چیز در دنیا ، انسانها، قدرت، ثروت و حتی تمدنها ، روزی از بین میروند و تنها حقیقت پایدار، ذات الهی است. در نگاه عرفانی، این آیه فقط درباره مرگ نیست؛ بلکه درباره فانی بودن غرور، تعلقات و هویتهای ظاهری انسان نیز سخن میگوید. پیام اصلی آیه این است که انسان نباید تمام وجود خود را به چیزهای موقتی گره بزند، بلکه باید به دنبال معنا، آگاهی، عشق و ارزشهای عمیقتر در زندگی باشد.
اگر ما این موضوع را درک کنیم ، از بسیاری حسادت ها ، تعلقات ، تکبر ها، دروغ ها و تلاش های ظاهری کاسته میشود و ما "انسان" میشویم.
در ویرگول بیشتر صحبت کرده ام که اگر فانی هستیم چرا باید تلاش کنیم ؟
https://vrgl.ir/jYTXy
❤9❤🔥2
وقتی مهاجم قبض هوش مصنوعی را به قربانی میدهد
با گسترش حملات مبتنی بر هوش مصنوعی، شاید در آینده مهاجمان دیگر حتی نیاز نداشته باشند زیرساخت پردازشی یا مدلهای سنگین خودشان را اجرا کنند. ایدهای که برخی مانند دیوید بیانکو آن را Living off the AI Land مینامند، میتواند به یکی از الگوهای جدید تهدید تبدیل شود؛ مشابه مفهومی که سالها در امنیت با عنوان Living off the Land شناخته میشد، جایی که مهاجم بهجای ابزار اختصاصی، از ابزارهای داخلی سیستم قربانی استفاده میکرد.
در این سناریوی جدید، مهاجم از همان AI موجود در سازمان یا روی دستگاه کاربر سوءاستفاده میکند. بهجای مصرف GPU، API Token یا زیرساخت خودش، بار پردازش و هزینه را به قربانی منتقل میکند. این موضوع میتواند اشکال مختلفی داشته باشد: سوءاستفاده از Copilotها، Agentهای داخلی، مدلهای متصل به دادههای سازمان، یا حتی تزریق Prompt برای وادار کردن سیستمهای AI به انجام تحلیل، تولید کد یا استخراج اطلاعات.
خطر اصلی فقط هزینه مالی نیست؛ بلکه مسئله اعتماد و مرزهای تصمیمگیری است. وقتی AI به بخشی از workflow عملیاتی تبدیل شود، مهاجم تلاش میکند همان AI را به ابزار اجرای حمله تبدیل کند.
در آینده، دفاع سایبری فقط محافظت از endpoint و network نخواهد بود؛ بلکه شامل کنترل «رفتار عاملهای هوشمند» نیز میشود. سازمانها باید telemetry مربوط به AI، مصرف token، رفتار agentها و زنجیره تصمیمگیری مدلها را همانقدر جدی بگیرند که امروز لاگهای SIEM و EDR را جدی میگیرند.
با گسترش حملات مبتنی بر هوش مصنوعی، شاید در آینده مهاجمان دیگر حتی نیاز نداشته باشند زیرساخت پردازشی یا مدلهای سنگین خودشان را اجرا کنند. ایدهای که برخی مانند دیوید بیانکو آن را Living off the AI Land مینامند، میتواند به یکی از الگوهای جدید تهدید تبدیل شود؛ مشابه مفهومی که سالها در امنیت با عنوان Living off the Land شناخته میشد، جایی که مهاجم بهجای ابزار اختصاصی، از ابزارهای داخلی سیستم قربانی استفاده میکرد.
در این سناریوی جدید، مهاجم از همان AI موجود در سازمان یا روی دستگاه کاربر سوءاستفاده میکند. بهجای مصرف GPU، API Token یا زیرساخت خودش، بار پردازش و هزینه را به قربانی منتقل میکند. این موضوع میتواند اشکال مختلفی داشته باشد: سوءاستفاده از Copilotها، Agentهای داخلی، مدلهای متصل به دادههای سازمان، یا حتی تزریق Prompt برای وادار کردن سیستمهای AI به انجام تحلیل، تولید کد یا استخراج اطلاعات.
خطر اصلی فقط هزینه مالی نیست؛ بلکه مسئله اعتماد و مرزهای تصمیمگیری است. وقتی AI به بخشی از workflow عملیاتی تبدیل شود، مهاجم تلاش میکند همان AI را به ابزار اجرای حمله تبدیل کند.
در آینده، دفاع سایبری فقط محافظت از endpoint و network نخواهد بود؛ بلکه شامل کنترل «رفتار عاملهای هوشمند» نیز میشود. سازمانها باید telemetry مربوط به AI، مصرف token، رفتار agentها و زنجیره تصمیمگیری مدلها را همانقدر جدی بگیرند که امروز لاگهای SIEM و EDR را جدی میگیرند.
👏2❤1
آکادمی آموزش روزبه 📚
وبینار عوامل موثر بر ارتقای کشف و بهروری در SOC های موجود - تجربه ی زیسته اطلاعات بیشتر را در بخش توضیحات لینک زیر بخوانید https://eseminar.tv/wb176454 دوشنبه 4 خرداد ماه در ایسمینار ساعت 20 ثبت نام زود هنگام با 40 درصد تخفیف
بررسی سرعت در SOC
مقوله Red Teaming یکی از مؤثرترین روشها برای افزایش بلوغ SOC و بهبود سرعت کشف تهدیدات است. بسیاری از SOCها دارای Rule و Alert هستند، اما تنها در زمان شبیهسازی حملات واقعی مشخص میشود که Detectionها تا چه حد کارآمدند. Red Team با اجرای تکنیکهای واقعی مهاجمان، ضعفهای Visibility، کمبود Telemetry، ضعف Correlation و Blind Spotهای سازمان را آشکار میکند. این فرآیند باعث بهبود Detection Engineering، کاهش False Negative و افزایش دقت Threat Hunting میشود. همچنین تحلیلگران SOC با مشاهده رفتار واقعی مهاجم، درک عمیقتری از Attack Chain، رفتارهای مشکوک و روشهای سریعتر شناسایی و پاسخ به حوادث پیدا میکنند.
در روز دوشنبه در ایسمینار از تجربه ۱۵ سال کار فنی بنده به نتایج خوبی خواهیم رسید .
مقوله Red Teaming یکی از مؤثرترین روشها برای افزایش بلوغ SOC و بهبود سرعت کشف تهدیدات است. بسیاری از SOCها دارای Rule و Alert هستند، اما تنها در زمان شبیهسازی حملات واقعی مشخص میشود که Detectionها تا چه حد کارآمدند. Red Team با اجرای تکنیکهای واقعی مهاجمان، ضعفهای Visibility، کمبود Telemetry، ضعف Correlation و Blind Spotهای سازمان را آشکار میکند. این فرآیند باعث بهبود Detection Engineering، کاهش False Negative و افزایش دقت Threat Hunting میشود. همچنین تحلیلگران SOC با مشاهده رفتار واقعی مهاجم، درک عمیقتری از Attack Chain، رفتارهای مشکوک و روشهای سریعتر شناسایی و پاسخ به حوادث پیدا میکنند.
در روز دوشنبه در ایسمینار از تجربه ۱۵ سال کار فنی بنده به نتایج خوبی خواهیم رسید .
❤5
👆دستورالعمل برپایی معماری Detection Engineering و مدیریت Detection مبتنی بر Git در SOC
تهیه شده توسط واحد MSSP شرکت هامون
جزئیات در لینک زیر
#MSSP #SOC #SOC_as_a_Service
لینک مقاله رو میتونید اینجا ببینید
https://vrgl.ir/F6Cif
تهیه شده توسط واحد MSSP شرکت هامون
جزئیات در لینک زیر
#MSSP #SOC #SOC_as_a_Service
لینک مقاله رو میتونید اینجا ببینید
https://vrgl.ir/F6Cif
👏3❤1
پروژه جاری که با اسپلانک مدیریت میکنم رو سوئیچ کردم رو مبحث Detection as code . ترند بازار جهانی هست ، لذا گفتم منم اونو در پروژه های کشور پیاده کنم
#تجربه
براتون در دو بخش توضیح میدم
بخش اول :Detection as Code در Splunk: از مدیریت دستی تا مدیریت مهندسیشده
در بسیاری از SOCها، Ruleها، Correlation Searchها و Dashboardهای Splunk مستقیماً از طریق GUI ساخته و ویرایش میشوند. این روش هنوز رایج است، اما در محیطهای بزرگ میتواند مشکلاتی مانند دشواری در ردگیری تغییرات، Rollback، کنترل کیفیت و انتقال منظم بین محیطهای Dev، Test و Prod ایجاد کند.
در SOCهای بالغتر، رویکرد Detection as Code بهتدریج استفاده میشود. در این مدل، محتوای تشخیص مانند یک دارایی نرمافزاری مدیریت میشود. SPL Queryها، Metadata، Severity، Data Source، Mapping به MITRE ATT&CK و Response Action میتوانند در Git Repository نگهداری شوند.
این کار باعث میشود تغییرات قابل بررسی، قابل بازگشت و قابل ممیزی باشند. همچنین تیمها میتوانند قبل از اعمال تغییرات در محیط عملیاتی، آنها را Peer Review و Test کنند.
استفاده از Sigma نیز میتواند کمک کند Detectionها تا حدی مستقلتر از Vendor طراحی شوند، هرچند تبدیل Sigma به SPL همیشه نیازمند بررسی، تنظیم و اعتبارسنجی انسانی است.
اینو در سه هفته ی اخیر شروع کردم
اگر #تجربه ای بود به اشتراک میگذارم
✅در ادامه تجربه ام با اسپلانک در Detection as code بخش دوم تجربه رو مینویسم.
بخش دوم : Detection Testing و CI/CD در Splunk
در SOCهای پیشرفته، نوشتن Detection پایان کار نیست. هر Detection باید از نظر منطق، کیفیت داده، کارایی، نرخ خطای مثبت و قابلیت اجرا در محیط واقعی بررسی شود. به همین دلیل، برخی تیمها از روشهایی الهامگرفته از مهندسی نرمافزار مانند Testing و CI/CD استفاده میکنند.
در این رویکرد، وقتی Detection جدیدی در Git ثبت میشود، میتوان مراحلی مانند Lint Check، بررسی ساختار Rule، اعتبارسنجی Metadata، بررسی Mapping به ATT&CK و تست SPL را اجرا کرد. سپس Rule ابتدا در محیط Dev یا Test Splunk بررسی و پس از تأیید به Production منتقل میشود.
ابزارهایی مانند Atomic Red Team، Caldera و Prelude Operator نیز میتوانند برای شبیهسازی رفتار مهاجم و ارزیابی عملکرد Detectionها استفاده شوند. البته این تستها معادل کامل Unit Test نرمافزار نیستند، چون کیفیت Telemetry و رفتار واقعی مهاجم همیشه متغیر است.
بنابراین، Detection as Code یک جایگزین کامل برای تحلیلگر نیست؛ بلکه روشی برای استانداردسازی، کنترل کیفیت و بهبود مستمر عملیات SOC است.
با این حال در اجرا فعلا به مشکلاتی بر خوردم که کل پایپ لاین هنوز فول عملیاتی نشده
در هفته های آینده از #تجربه ام در Detection as code بیشتر مینویسم .
به امید بالغ شدن SOC های کشور
#تجربه
براتون در دو بخش توضیح میدم
بخش اول :Detection as Code در Splunk: از مدیریت دستی تا مدیریت مهندسیشده
در بسیاری از SOCها، Ruleها، Correlation Searchها و Dashboardهای Splunk مستقیماً از طریق GUI ساخته و ویرایش میشوند. این روش هنوز رایج است، اما در محیطهای بزرگ میتواند مشکلاتی مانند دشواری در ردگیری تغییرات، Rollback، کنترل کیفیت و انتقال منظم بین محیطهای Dev، Test و Prod ایجاد کند.
در SOCهای بالغتر، رویکرد Detection as Code بهتدریج استفاده میشود. در این مدل، محتوای تشخیص مانند یک دارایی نرمافزاری مدیریت میشود. SPL Queryها، Metadata، Severity، Data Source، Mapping به MITRE ATT&CK و Response Action میتوانند در Git Repository نگهداری شوند.
این کار باعث میشود تغییرات قابل بررسی، قابل بازگشت و قابل ممیزی باشند. همچنین تیمها میتوانند قبل از اعمال تغییرات در محیط عملیاتی، آنها را Peer Review و Test کنند.
استفاده از Sigma نیز میتواند کمک کند Detectionها تا حدی مستقلتر از Vendor طراحی شوند، هرچند تبدیل Sigma به SPL همیشه نیازمند بررسی، تنظیم و اعتبارسنجی انسانی است.
اینو در سه هفته ی اخیر شروع کردم
اگر #تجربه ای بود به اشتراک میگذارم
✅در ادامه تجربه ام با اسپلانک در Detection as code بخش دوم تجربه رو مینویسم.
بخش دوم : Detection Testing و CI/CD در Splunk
در SOCهای پیشرفته، نوشتن Detection پایان کار نیست. هر Detection باید از نظر منطق، کیفیت داده، کارایی، نرخ خطای مثبت و قابلیت اجرا در محیط واقعی بررسی شود. به همین دلیل، برخی تیمها از روشهایی الهامگرفته از مهندسی نرمافزار مانند Testing و CI/CD استفاده میکنند.
در این رویکرد، وقتی Detection جدیدی در Git ثبت میشود، میتوان مراحلی مانند Lint Check، بررسی ساختار Rule، اعتبارسنجی Metadata، بررسی Mapping به ATT&CK و تست SPL را اجرا کرد. سپس Rule ابتدا در محیط Dev یا Test Splunk بررسی و پس از تأیید به Production منتقل میشود.
ابزارهایی مانند Atomic Red Team، Caldera و Prelude Operator نیز میتوانند برای شبیهسازی رفتار مهاجم و ارزیابی عملکرد Detectionها استفاده شوند. البته این تستها معادل کامل Unit Test نرمافزار نیستند، چون کیفیت Telemetry و رفتار واقعی مهاجم همیشه متغیر است.
بنابراین، Detection as Code یک جایگزین کامل برای تحلیلگر نیست؛ بلکه روشی برای استانداردسازی، کنترل کیفیت و بهبود مستمر عملیات SOC است.
با این حال در اجرا فعلا به مشکلاتی بر خوردم که کل پایپ لاین هنوز فول عملیاتی نشده
در هفته های آینده از #تجربه ام در Detection as code بیشتر مینویسم .
به امید بالغ شدن SOC های کشور
👏4❤1🤝1
ابزار OpenClaw یک Agent مبتنی بر هوش مصنوعی است که برخلاف Chatbotهای سنتی، فقط پاسخ تولید نمیکند بلکه میتواند «عمل» نیز انجام دهد. به بیان ساده، اگر ChatGPT شبیه یک مشاور باشد، OpenClaw بیشتر شبیه یک دستیار اجرایی است که میتواند فایلها را بخواند، دستورات اجرا کند، مرورگر را کنترل کند، APIها را فراخوانی کند و وظایف چندمرحلهای را بهصورت خودکار انجام دهد.
معماری OpenClaw معمولاً از چند بخش تشکیل میشود: مدل زبانی (LLM)، موتور تصمیمگیری، حافظه بلندمدت، ابزارها (Tools) و محیط اجرا. این ساختار باعث میشود Agent بتواند وظایف پیچیده را برنامهریزی و اجرا کند.
اهمیت OpenClaw صرفاً بهدلیل قابلیتهای آن نیست؛ بلکه بهدلیل ریسکهای امنیتی آن نیز مورد توجه قرار گرفته است. وقتی یک Agent به فایلها، Shell، ایمیل، مرورگر و سرویسهای مختلف دسترسی دارد، حملاتی مانند Prompt Injection، Memory Poisoning و Tool Abuse میتوانند از یک پاسخ اشتباه فراتر رفته و به اقدامات اشتباه منجر شوند.
به همین دلیل، در طراحی Agentهای مدرن، مفاهیمی مانند Least Privilege، Human Approval، Logging، Monitoring و Sandbox اهمیت بسیار زیادی پیدا میکنند.
معماری OpenClaw معمولاً از چند بخش تشکیل میشود: مدل زبانی (LLM)، موتور تصمیمگیری، حافظه بلندمدت، ابزارها (Tools) و محیط اجرا. این ساختار باعث میشود Agent بتواند وظایف پیچیده را برنامهریزی و اجرا کند.
اهمیت OpenClaw صرفاً بهدلیل قابلیتهای آن نیست؛ بلکه بهدلیل ریسکهای امنیتی آن نیز مورد توجه قرار گرفته است. وقتی یک Agent به فایلها، Shell، ایمیل، مرورگر و سرویسهای مختلف دسترسی دارد، حملاتی مانند Prompt Injection، Memory Poisoning و Tool Abuse میتوانند از یک پاسخ اشتباه فراتر رفته و به اقدامات اشتباه منجر شوند.
به همین دلیل، در طراحی Agentهای مدرن، مفاهیمی مانند Least Privilege، Human Approval، Logging، Monitoring و Sandbox اهمیت بسیار زیادی پیدا میکنند.
❤3👏3
نکته ای در کانفیگ UTM هایی چون فورتی گیت
برای ارتقای عملکرد SOC
چرا Context و Performance در تنظیم IPS مهمتر از فعالسازی ساده هستند؟
یکی از اشتباهات رایج در پیادهسازی IPS این است که سازمانها تصور میکنند فعالسازی تعداد بیشتری Signature به معنای امنیت بیشتر است، درحالیکه Context محیط اهمیت بسیار بالاتری دارد. بهعنوان مثال، اگر سازمان هیچ Linux Server نداشته باشد، فعالسازی Signatureهای Exploit مرتبط با Linux ممکن است صرفاً باعث افزایش مصرف منابع و تولید Alertهای غیرضروری شود. IPS باید متناسب با داراییها، سرویسها، سیستمعاملها و معماری واقعی سازمان طراحی شود.
از طرف دیگر، Performance یکی از مهمترین چالشهای عملیاتی IPS است. IPS بهصورت ذاتی پردازشبر است و ترکیب آن با SSL Inspection، Antivirus و Application Control میتواند فشار قابلتوجهی بر تجهیزات وارد کند. همچنین تفاوت Flow Mode و Proxy Mode میتواند تأثیر مستقیمی بر Latency و Throughput داشته باشد. به همین دلیل، Sizing صحیح، Capacity Planning و طراحی Profile مناسب، نقش کلیدی در موفقیت عملیاتی IPS دارند.
#آکادمی_روزبه
#MSSP #هامون
برای ارتقای عملکرد SOC
چرا Context و Performance در تنظیم IPS مهمتر از فعالسازی ساده هستند؟
یکی از اشتباهات رایج در پیادهسازی IPS این است که سازمانها تصور میکنند فعالسازی تعداد بیشتری Signature به معنای امنیت بیشتر است، درحالیکه Context محیط اهمیت بسیار بالاتری دارد. بهعنوان مثال، اگر سازمان هیچ Linux Server نداشته باشد، فعالسازی Signatureهای Exploit مرتبط با Linux ممکن است صرفاً باعث افزایش مصرف منابع و تولید Alertهای غیرضروری شود. IPS باید متناسب با داراییها، سرویسها، سیستمعاملها و معماری واقعی سازمان طراحی شود.
از طرف دیگر، Performance یکی از مهمترین چالشهای عملیاتی IPS است. IPS بهصورت ذاتی پردازشبر است و ترکیب آن با SSL Inspection، Antivirus و Application Control میتواند فشار قابلتوجهی بر تجهیزات وارد کند. همچنین تفاوت Flow Mode و Proxy Mode میتواند تأثیر مستقیمی بر Latency و Throughput داشته باشد. به همین دلیل، Sizing صحیح، Capacity Planning و طراحی Profile مناسب، نقش کلیدی در موفقیت عملیاتی IPS دارند.
#آکادمی_روزبه
#MSSP #هامون
❤3
چرا TOGAF برای طراحی SOC و MSSP اهمیت دارد؟
#تجربه
بسیاری از سازمانها تصور میکنند ساخت SOC صرفاً به خرید SIEM، استقرار EDR و استخدام تحلیلگر محدود میشود؛ درحالیکه مشکل اصلی بسیاری از SOCها، نبود معماری و همراستایی با کسبوکار است. TOGAF بهعنوان یک Enterprise Architecture Framework کمک میکند SOC صرفاً بهعنوان مجموعهای از ابزارها دیده نشود، بلکه بهعنوان یک Capability سازمانی طراحی شود.
استاندارد TOGAF باعث میشود طراحی SOC از چهار زاویه Business، Data، Application و Technology انجام شود. این رویکرد کمک میکند نیازهای کسبوکار، الزامات امنیتی، جریان دادهها، فرآیندها و فناوریها بهصورت یکپارچه طراحی شوند.
همچنین TOGAF در Capability Mapping، طراحی Roadmap بلوغ، تعریف Target Architecture و جلوگیری از ساخت SOCهای جزیرهای بسیار مؤثر است. اگرچه TOGAF ابزار Detection Engineering یا Framework عملیاتی SOC نیست، اما برای معماران امنیت، طراحان MSSP، مدیران امنیت و مشاوران، یک ابزار ارزشمند برای طراحی صحیح و مقیاسپذیر SOC محسوب میشود.
#تجربه
بسیاری از سازمانها تصور میکنند ساخت SOC صرفاً به خرید SIEM، استقرار EDR و استخدام تحلیلگر محدود میشود؛ درحالیکه مشکل اصلی بسیاری از SOCها، نبود معماری و همراستایی با کسبوکار است. TOGAF بهعنوان یک Enterprise Architecture Framework کمک میکند SOC صرفاً بهعنوان مجموعهای از ابزارها دیده نشود، بلکه بهعنوان یک Capability سازمانی طراحی شود.
استاندارد TOGAF باعث میشود طراحی SOC از چهار زاویه Business، Data، Application و Technology انجام شود. این رویکرد کمک میکند نیازهای کسبوکار، الزامات امنیتی، جریان دادهها، فرآیندها و فناوریها بهصورت یکپارچه طراحی شوند.
همچنین TOGAF در Capability Mapping، طراحی Roadmap بلوغ، تعریف Target Architecture و جلوگیری از ساخت SOCهای جزیرهای بسیار مؤثر است. اگرچه TOGAF ابزار Detection Engineering یا Framework عملیاتی SOC نیست، اما برای معماران امنیت، طراحان MSSP، مدیران امنیت و مشاوران، یک ابزار ارزشمند برای طراحی صحیح و مقیاسپذیر SOC محسوب میشود.
❤4
مشکلات شایع Parsing لاگهای ویندوز در اسپلانک
بسیاری از مشکلات SOCها از مرحله Detection شروع نمیشود؛ بلکه از Data Quality و Parsing اشتباه لاگها آغاز میشود. یکی از رایجترین مشکلات، تنظیم نادرست Sourcetype است که باعث میشود Field Extraction و Detectionها بهدرستی کار نکنند. انتخاب بین فرمت XML و Classic Event Format نیز اهمیت زیادی دارد؛ XML معمولاً ساختاریافتهتر است و برای Detection مناسبتر عمل میکند.
یکی دیگر از مشکلات رایج، شکست در استخراج فیلدها است؛ بهطوریکه اطلاعاتی مانند User، Process Name یا Logon Type ممکن است بهدرستی Parse نشوند. مشکلات Timestamp نیز میتوانند زمان واقعی رخداد را با زمان نمایش دادهشده در Dashboard متفاوت کنند.
در محیطهای چندزبانه، Localization نیز چالش مهمی است؛ زیرا تغییر زبان سیستمها میتواند Regexها و Detection Content را خراب کند. همچنین Event Loss ناشی از Queue Full، مشکلات Forwarder یا Permissionها میتواند باعث از دست رفتن لاگهای حیاتی شود.
#MSSP #تجربه #هامون
👇👇
بسیاری از مشکلات SOCها از مرحله Detection شروع نمیشود؛ بلکه از Data Quality و Parsing اشتباه لاگها آغاز میشود. یکی از رایجترین مشکلات، تنظیم نادرست Sourcetype است که باعث میشود Field Extraction و Detectionها بهدرستی کار نکنند. انتخاب بین فرمت XML و Classic Event Format نیز اهمیت زیادی دارد؛ XML معمولاً ساختاریافتهتر است و برای Detection مناسبتر عمل میکند.
یکی دیگر از مشکلات رایج، شکست در استخراج فیلدها است؛ بهطوریکه اطلاعاتی مانند User، Process Name یا Logon Type ممکن است بهدرستی Parse نشوند. مشکلات Timestamp نیز میتوانند زمان واقعی رخداد را با زمان نمایش دادهشده در Dashboard متفاوت کنند.
در محیطهای چندزبانه، Localization نیز چالش مهمی است؛ زیرا تغییر زبان سیستمها میتواند Regexها و Detection Content را خراب کند. همچنین Event Loss ناشی از Queue Full، مشکلات Forwarder یا Permissionها میتواند باعث از دست رفتن لاگهای حیاتی شود.
#MSSP #تجربه #هامون
👇👇
❤2
آکادمی آموزش روزبه 📚
مشکلات شایع Parsing لاگهای ویندوز در اسپلانک بسیاری از مشکلات SOCها از مرحله Detection شروع نمیشود؛ بلکه از Data Quality و Parsing اشتباه لاگها آغاز میشود. یکی از رایجترین مشکلات، تنظیم نادرست Sourcetype است که باعث میشود Field Extraction و Detectionها…
برخی Eventها نیز حجم زیادی از داده تولید میکنند و باعث افزایش EPS و هزینه لایسنس میشوند. به همین دلیل، رویکرد صحیح معمولاً این است:
Collection > Parsing > Validation >CIM > Detection
زیرا در SOC، کیفیت داده تقریباً نیمی از موفقیت Detection است.
Collection > Parsing > Validation >CIM > Detection
زیرا در SOC، کیفیت داده تقریباً نیمی از موفقیت Detection است.
❤2
خبر امروز
دوستانی که از اینترنت قطع بودید و یا سیستم وصله کردن ندارید بدانید:
چندین آسیبپذیری جدید در 7-Zip کشف شده که میتوانند به مهاجم اجازه دهند از طریق فایلهای فشرده دستکاریشده، کد مخرب اجرا کند. این ضعفها عمدتاً به نحوه پردازش Symbolic Linkها، Parsing فایلهای ZIP و Handlerهای آرشیو مربوط هستند. در برخی سناریوها، تنها باز کردن یا Extract کردن یک فایل آلوده میتواند منجر به نوشتن فایل خارج از مسیر مورد انتظار و در نهایت Remote Code Execution شود. مشکل بزرگتر این است که 7-Zip مکانیزم Auto Update ندارد و بسیاری از سیستمها هنوز نسخههای آسیبپذیر را اجرا میکنند. توصیه اصلی، بهروزرسانی فوری به نسخههای جدید و اجتناب از باز کردن فایلهای فشرده ناشناس است
🔴نکته: با حضور هوش مصنوعی ، این آسیب پذیری بسرعت دارای اکسپلویت شده و خیلی سریعتر از آنچه تصورش را بکنید علیه شما استفاده خواهد شد.
راهکار: راه اندازی مدیریت وصله به کمک Desktop central
https://gbhackers.com/multiple-7-zip-vulnerabilities-arbitrary-code-execution/
دوستانی که از اینترنت قطع بودید و یا سیستم وصله کردن ندارید بدانید:
چندین آسیبپذیری جدید در 7-Zip کشف شده که میتوانند به مهاجم اجازه دهند از طریق فایلهای فشرده دستکاریشده، کد مخرب اجرا کند. این ضعفها عمدتاً به نحوه پردازش Symbolic Linkها، Parsing فایلهای ZIP و Handlerهای آرشیو مربوط هستند. در برخی سناریوها، تنها باز کردن یا Extract کردن یک فایل آلوده میتواند منجر به نوشتن فایل خارج از مسیر مورد انتظار و در نهایت Remote Code Execution شود. مشکل بزرگتر این است که 7-Zip مکانیزم Auto Update ندارد و بسیاری از سیستمها هنوز نسخههای آسیبپذیر را اجرا میکنند. توصیه اصلی، بهروزرسانی فوری به نسخههای جدید و اجتناب از باز کردن فایلهای فشرده ناشناس است
🔴نکته: با حضور هوش مصنوعی ، این آسیب پذیری بسرعت دارای اکسپلویت شده و خیلی سریعتر از آنچه تصورش را بکنید علیه شما استفاده خواهد شد.
راهکار: راه اندازی مدیریت وصله به کمک Desktop central
https://gbhackers.com/multiple-7-zip-vulnerabilities-arbitrary-code-execution/
GBHackers Security | #1 Globally Trusted Cyber Security News Platform
Multiple 7-Zip Vulnerabilities Enable Arbitrary Code Execution
Multiple memory safety bugs in 7‑Zip 26.00 allow remote attackers to leak sensitive data and, in at least one case, execute arbitrary code when a victim opens a crafted archive file.
👍2❤1👏1
🔴خطر و راهکار کشف
روش کشف استفاده از آسیب پذیری مطرح در لینک زیر
در صورت استفاده مهاجم از آسیب پذیری لینک زیر ، اینها رو در SOC خواهیم دید
✴️
Many CLDAP Requests
High Volume UDP/389
Unknown Source → DC
✴️
lsass.exe crash
Unexpected reboot
Netlogon failure
✴️
DC reboot
Service interruption
Authentication failures
✅️
index=network dest_port=389 protocol=udp
| stats count by src_ip dest_ip
| where count > 100
⚫️اولویت دفاع
Patch Domain Controllerها
مانیتور UDP/389
مانیتور Crash / Reboot DC
Network Segmentation
انجام Hunt روی Netlogon anomalies
این از آن دسته CVEهاست که اگر سازمان Splunk ES، SOC یا MSSP دارد، نباید صرفاً Vulnerability Management بماند؛ باید Detection Use Case هم داشته باشد.
#MSSP #هامون
https://github.com/0xABCD01/CVE-2026-41089
روش کشف استفاده از آسیب پذیری مطرح در لینک زیر
در صورت استفاده مهاجم از آسیب پذیری لینک زیر ، اینها رو در SOC خواهیم دید
✴️
Many CLDAP Requests
High Volume UDP/389
Unknown Source → DC
✴️
lsass.exe crash
Unexpected reboot
Netlogon failure
✴️
DC reboot
Service interruption
Authentication failures
✅️
index=network dest_port=389 protocol=udp
| stats count by src_ip dest_ip
| where count > 100
⚫️اولویت دفاع
Patch Domain Controllerها
مانیتور UDP/389
مانیتور Crash / Reboot DC
Network Segmentation
انجام Hunt روی Netlogon anomalies
این از آن دسته CVEهاست که اگر سازمان Splunk ES، SOC یا MSSP دارد، نباید صرفاً Vulnerability Management بماند؛ باید Detection Use Case هم داشته باشد.
#MSSP #هامون
https://github.com/0xABCD01/CVE-2026-41089
GitHub
GitHub - 0xABCD01/CVE-2026-41089: Netlogon and CLDAP vulnerability research with a proof of concept.
Netlogon and CLDAP vulnerability research with a proof of concept. - 0xABCD01/CVE-2026-41089
❤4
آیا EDR مرده است؟
هر چند وقت یکبار با ظهور فناوریهای جدید، این سؤال دوباره مطرح میشود: آیا EDR دیگر کارایی ندارد؟ پاسخ کوتاه این است: خیر؛ اما نقش آن تغییر کرده است.
سالها قبل، داشتن EDR برای بسیاری از سازمانها یک مزیت رقابتی محسوب میشد، اما امروز تقریباً به یک الزام پایه تبدیل شده است. مهاجمان مدرن، مخصوصاً با کمک AI، بهتر از گذشته میدانند EDR چگونه کار میکند، چگونه از دید آن پنهان شوند و چگونه از ابزارهای قانونی سیستم برای حمله استفاده کنند.
مشکل اصلی این نیست که EDR ضعیف شده؛ مشکل این است که بسیاری انتظار دارند EDR بهتنهایی امنیت ایجاد کند.
امروز EDR بیشتر شبیه یک Sensor قدرتمند است؛ نه یک راهکار کامل. Detection Engineering، Hardening، Threat Hunting، Telemetry مناسب و Incident Response سریع، همان بخشهایی هستند که EDR را ارزشمند میکنند.
بنابراین EDR نمرده است؛ بلکه از قهرمان اصلی به "بخشی از یک اکوسیستم دفاعی" تبدیل شده است.
هر چند وقت یکبار با ظهور فناوریهای جدید، این سؤال دوباره مطرح میشود: آیا EDR دیگر کارایی ندارد؟ پاسخ کوتاه این است: خیر؛ اما نقش آن تغییر کرده است.
سالها قبل، داشتن EDR برای بسیاری از سازمانها یک مزیت رقابتی محسوب میشد، اما امروز تقریباً به یک الزام پایه تبدیل شده است. مهاجمان مدرن، مخصوصاً با کمک AI، بهتر از گذشته میدانند EDR چگونه کار میکند، چگونه از دید آن پنهان شوند و چگونه از ابزارهای قانونی سیستم برای حمله استفاده کنند.
مشکل اصلی این نیست که EDR ضعیف شده؛ مشکل این است که بسیاری انتظار دارند EDR بهتنهایی امنیت ایجاد کند.
امروز EDR بیشتر شبیه یک Sensor قدرتمند است؛ نه یک راهکار کامل. Detection Engineering، Hardening، Threat Hunting، Telemetry مناسب و Incident Response سریع، همان بخشهایی هستند که EDR را ارزشمند میکنند.
بنابراین EDR نمرده است؛ بلکه از قهرمان اصلی به "بخشی از یک اکوسیستم دفاعی" تبدیل شده است.
❤6