سایت lolrmm.io یک منبع فوق‌العاده (و رایگان) برای مهندسان تشخیص (Detection Engineers) است تا بتوانند کشف های سفارشی ایجاد کنند که در صورت نصب هرگونه ابزار Remote Monitoring and Management (RMM) یا Remote Desktop / Remote Support روی دسکتاپ‌ها یا سرورهای شما، به SOC هشدار بدهد.
اگر در سازمان شما سیاستی وجود دارد که مشخص می‌کند چه ابزارهای ریموتی مجاز هستند و چگونه باید نصب شوند، این ابزار به شما کمک می‌کند هر زمان که مهاجمان از این ابزارها برای دسترسی به شبکه سوءاستفاده می‌کنند، آن را شناسایی کنید.
#تجربه
مهاجمان در سطح گسترده همچنان با نرخ بالایی از این ابزارهای RMM/RDS سوءاستفاده می‌کنند. بنابراین تمرکز روی طراحی و پیاده‌سازی این نوع دتکشن‌ها، هم ارزشمند است و هم استفاده‌ی بهینه‌ای از زمان محدود مهندسی تشخیص شما محسوب می‌شود.

برنامه CI Fortify از سوی Cybersecurity and Infrastructure Security Agency نشان‌دهنده یک تغییر پارادایم مهم در امنیت زیرساخت‌های حیاتی است؛ تغییری از تمرکز صرف بر «پیشگیری از نفوذ» به سمت «تاب‌آوری در شرایط نفوذ». این رویکرد به‌ویژه در حوزه Industrial Control Systems اهمیت دارد، جایی که اختلال در سرویس می‌تواند پیامدهای فیزیکی و اجتماعی گسترده‌ای ایجاد کند.

مقوله CI Fortify بر این فرض استوار است که در سناریوهای واقعی - به‌خصوص در بحران‌های ژئوپلیتیکی- مهاجمان ممکن است از قبل در شبکه حضور داشته باشند و ارتباطات خارجی نیز ناپایدار یا قطع شوند. بنابراین، سازمان‌ها باید معماری خود را به‌گونه‌ای طراحی کنند که حتی در شرایط compromise نیز بتوانند خدمات حیاتی را ادامه دهند. این شامل ایزوله‌سازی سیستم‌های حساس، کاهش وابستگی به سرویس‌های بیرونی و طراحی برای «عملیات در حالت کاهش‌یافته» است.

از منظر عملیاتی، این رویکرد با مفاهیمی مانند Cyber Resilience و طراحی مبتنی بر failure هم‌راستا است. در این مدل، موفقیت امنیتی نه در جلوگیری کامل از نفوذ، بلکه در توانایی حفظ عملکرد و بازیابی سریع تعریف می‌شود. در نهایت، CI Fortify سازمان‌ها را وادار می‌کند که امنیت را نه به‌عنوان یک لایه دفاعی، بلکه به‌عنوان بخشی از طراحی سیستم و تداوم کسب‌وکار ببینند.



https://www.cisa.gov/topics/industrial-control-systems/ci-fortify

Crowdstrike threat hunting report 2025

2026 GLOBAL THREAT REPORT

وقتی رفتار عادی کاربر به Execution Path تبدیل می‌شود

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

یکی از خطرناک‌ترین سوءبرداشت‌ها در امنیت سایبری این است که فقط رفتارهای «غیرعادی» یا ابزارهای پیچیده می‌توانند منجر به compromise شوند. در حالی‌که بسیاری از حملات مدرن دقیقاً از دل رفتارهای روزمره کاربران شکل می‌گیرند.
آسیب‌پذیری Command Injection در Context Menu ویندوز نمونه بسیار خوبی از این واقعیت است.
عملی کاملاً طبیعی مانند Shift + Right Click روی یک پوشه و انتخاب گزینه «Open PowerShell window here» می‌تواند به execution ناخواسته کد منجر شود. مسئله اصلی نه PowerShell است و نه حتی privilege escalation؛ بلکه این واقعیت است که یک interaction عادی کاربر، به execution path تبدیل شده است.
این دقیقاً همان بخشی است که در بسیاری از Threat Modelها نادیده گرفته می‌شود.
اغلب تیم‌ها هنگام طراحی دفاع امنیتی روی مواردی مانند malware execution، exploit chain یا persistence تمرکز می‌کنند؛ اما کمتر این سؤال را می‌پرسند:

«کدام رفتار عادی کاربر می‌تواند به surface اجرای کد تبدیل شود؟»

در دنیای واقعی، مهاجمان الزاماً به دنبال exploitهای پیچیده kernel نیستند. گاهی کافی است فرآیندی پیدا کنند که:
کاربر به آن اعتماد دارد،
به‌صورت روزمره استفاده می‌شود،
و در پشت‌صحنه command construction ناامن انجام می‌دهد.
همین mindset باعث شده در سال‌های اخیر تکنیک‌های Living-off-the-Land اهمیت بیشتری پیدا کنند؛ زیرا مهاجم از ابزارها و workflowهای legitimate سیستم علیه خود سیستم استفاده می‌کند.
نمونه ای که گفته شد یک درس مهم برای معماران امنیت، SOCها و حتی توسعه‌دهندگان دارد:
هر UI action، context menu، automation flow یا helper script می‌تواند عملاً بخشی از attack surface باشد؛ حتی اگر سال‌ها «قابلیت عادی سیستم‌عامل» تلقی شده باشد.
در امنیت مدرن، صرفاً بررسی executableها کافی نیست؛ باید مسیرهای تبدیل «رفتار عادی» به «execution» را هم مدل‌سازی کرد.



https://specterops.io/blog/2026/05/07/shift-happens-uncovering-two-built-in-command-injections-in-windows-context-menus/

IR playbook

تشخیص Sandbox توسط بدافزارها
✅دقت در انتخاب سندباکس

نکاتی در زمینه این موضوع در ذیل بیان میکنم امید در انتخاب سند باکس مفید واقع شود.
#تجربه

بدافزارهای پیشرفته برای فرار از تحلیل پویا در Sandbox، از مجموعه‌ای از تکنیک‌های Anti‑VM، Anti‑Sandbox و Anti‑Debug استفاده می‌کنند و با جمع‌آوری چندین شاخص تصمیم می‌گیرند که در محیط واقعی اجرا شده‌اند یا در محیط تحلیل.

یکی از روش‌های رایج، Fingerprinting سخت‌افزار و هایپروایزر است. بدافزار با استفاده از دستوراتی مانند CPUID وجود Hypervisor را بررسی می‌کند یا مقادیر SMBIOS/DMI را برای یافتن نشانه‌هایی مانند VMware و VirtualBox تحلیل می‌کند. همچنین بررسی MAC Address OUI، تعداد غیرعادی هسته‌های CPU، مدل دیسک و سایر Artifactهای ماشین مجازی می‌تواند نشانه‌ای از Sandbox باشد.

دسته دیگر، حملات زمانی (Timing Attacks) است. بدافزار با اندازه‌گیری تأخیر اجرای دستورات از طریق RDTSC یا QueryPerformanceCounter به دنبال افزایش latency ناشی از VM‑exit یا Hookهای امنیتی می‌گردد.

در سطح Anti‑Debug، توابعی مانند IsDebuggerPresent یا بررسی ساختار PEB برای شناسایی دیباگر استفاده می‌شوند. برخی نمونه‌ها همچنین وجود ابزارهای EDR یا Breakpointها را نیز بررسی می‌کنند.

در نهایت، بسیاری از بدافزارها از Behavioral Gating استفاده می‌کنند؛ یعنی تا زمانی که نشانه‌هایی از تعامل واقعی کاربر، داده‌های کاربری، یا شرایط شبکه معتبر مشاهده نشود، payload اصلی فعال نمی‌شود. این رویکرد چندعاملی باعث می‌شود تحلیل خودکار Sandbox دشوارتر شود.


❓حالا ، Sandbox شما حرفه ای است ؟

هانت با 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 فراهم می‌کند.

آیا ضعف در آموزش ریاضی بر کیفیت متخصصان امنیت سایبری اثر می‌گذارد؟


وقتی درباره امنیت سایبری صحبت می‌شود، بسیاری تصور می‌کنند مهم‌ترین مهارت‌ها شامل کار با ابزارها، شناخت حملات یا یادگیری فناوری‌های جدید است. اما در عمل، یکی از عوامل پنهان و بسیار اثرگذار در کیفیت متخصصان امنیت، نوع تفکری است که سیستم آموزشی در افراد ایجاد می‌کند؛ و آموزش ریاضی در این میان نقش مهمی دارد.
موضوع فقط رمزنگاری یا فرمول‌های پیچیده نیست. حتی اگر بخش Cryptography را کنار بگذاریم، امنیت سایبری همچنان به تفکر تحلیلی، مدل‌سازی ذهنی و توانایی کشف الگو وابسته است. یک تحلیل‌گر SOC حرفه‌ای باید بتواند میان هزاران لاگ و Event، ارتباط‌های غیرآشکار را تشخیص دهد و از دل رفتارهای ظاهراً عادی، نشانه‌های حمله را استخراج کند. این فرآیند بیشتر شبیه تحلیل سیستم و استدلال منطقی است تا صرفاً کار با ابزارها.
آموزش ریاضی قوی معمولاً مهارت‌هایی مانند تفکر ساختاریافته، تحلیل علت و معلول، abstraction و reasoning را تقویت می‌کند؛ مهارت‌هایی که در Threat Hunting، Detection Engineering و DFIR بسیار حیاتی‌اند. در مقابل، ضعف در این حوزه می‌تواند باعث شود بخشی از نیروها بیش از حد ابزارمحور شوند و در تحلیل عمیق، طراحی Detection Logic یا تفکر adversarial ضعف داشته باشند.
به همین دلیل، بسیاری از متخصصان برجسته امنیت الزاماً کسانی نیستند که فقط مدارک متعدد دارند؛ بلکه افرادی هستند که قدرت تحلیل سیستمی و ذهن ساختاریافته‌تری دارند. امنیت سایبری بیش از آنکه صرفاً یک مهارت فنی باشد، یک شیوه تفکر تحلیلی است؛ و آموزش ریاضی می‌تواند یکی از پایه‌های شکل‌گیری این ذهنیت باشد.

خصوصیات امنیتی جدید اندروید


https://blog.google/security/whats-new-in-android-security-privacy-2026/

چرا در مورد فورتی وب مینویسم ؟

آره کار من با فورتی وب به حدود ۱۳ تا ۱۰ سال پیش برمیگرده ؛ از نصب تا تیونینگ و بررسی لاگ.

اما چیزی که این روزها دغدغه من شده ، کانفیگ نامناسب برای تعداد بالای وف هایی هست که میبینم. لذا کشف و مقابله درستی نداریم و دیتا سورس SOC های ما هم ناکامله.

دوستان

وف قرار هست حملات رو کشف کنه و مقابله ، لاگش هم در SOC خیلی حیاتیه
اما
ما با عدم تنظیم مناسب ، اونو از یه بنز به پراید تقلیل دادیم !!


این روزها وف هایی میبینم که باید به حال مالکان اونها ناراحت شد . اونچه من میبینم اینه که تنظیمات وف به یه عنصر لاکچری در کشور بدل شده درحالی‌که یکی از اقلام ضروری کالابرگ!! سازمانیه

لذا
یه دپارتمان در شرکت هامون تشکیل دادم که یکی از کاراش فقط تیونینگ وف هست. پس یکی از اقلام کاتالوگ خدمات شرکت هامون شده "ارتقای عملیاتی وف"
اینجوری هم کنترل مهمی چون وف درست در مدار هست هم SOC شما میتونه یه قدم ارتقا پیدا کنه

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


#خدمت_اختصاصی

وبینار عوامل موثر بر ارتقای کشف و بهروری در SOC های موجود - تجربه ی زیسته

اطلاعات بیشتر را در بخش توضیحات لینک زیر بخوانید
https://eseminar.tv/wb176454


دوشنبه 4 خرداد ماه در ایسمینار ساعت 20

ثبت نام زود هنگام با 40 درصد تخفیف

تخفیف ثبت نام تا 31 اردیبهشت برقرار است

شهود انسانی در برابر سرعت هوش مصنوعی؛ آینده جدید Threat Hunting

مقوله Threat Hunting مدرن وارد مرحله‌ای جدید و پیچیده شده است. سال‌ها، موفق‌ترین عملیات‌های هانت وابسته به تجربه، شهود و درک انسانی تحلیلگران بود. یک Threat Hunter حرفه‌ای می‌توانست رفتارهای غیرعادی مهاجم را از میان حجم عظیمی از داده‌ها تشخیص دهد، سیگنال‌های ضعیف را به هم متصل کند و فرضیات اشتباه را به چالش بکشد. به همین دلیل هنوز بسیاری معتقدند که «Threat Hunting ذاتاً انسان‌محور است.»

اما ظهور تهدیدات مبتنی بر هوش مصنوعی، معادله را تغییر داده است. مهاجمان اکنون می‌توانند با سرعت ماشین، عملیات Reconnaissance، فیشینگ، تولید بدافزار، تحلیل هدف و حتی حملات تطبیقی انجام دهند. در چنین شرایطی، مدل‌های سنتی هانت که کاملاً متکی به انسان هستند، دیگر سرعت کافی ندارند. اینجاست که یک سؤال مهم مطرح می‌شود: چگونه می‌توان عمق تحلیل انسانی را با سرعت AI ترکیب کرد؟

پاسخ در حذف انسان نیست، بلکه در تقویت اوست. هوش مصنوعی می‌تواند تحلیل حجم عظیم telemetry، correlation، anomaly detection و triage اولیه را انجام دهد، در حالی که تحلیلگر انسانی روی hypothesis building، تفسیر رفتار مهاجم و تصمیم‌گیری نهایی تمرکز می‌کند.

آینده Threat Hunting نه کاملاً انسانی خواهد بود و نه کاملاً خودکار؛ بلکه متعلق به تیم‌هایی است که بتوانند قضاوت انسانی را با سرعت پردازش AI ترکیب کنند.

اگر همه چیز فانی است ، چرا تلاش کنیم ؟!

آیهٔ «كُلُّ مَنْ عَلَيْهَا فَانٍ» از سوره الرحمن، یکی از عمیق‌ترین آیات قرآن درباره ناپایداری جهان است. این آیه یادآوری می‌کند که همه چیز در دنیا ، انسان‌ها، قدرت، ثروت و حتی تمدن‌ها ، روزی از بین می‌روند و تنها حقیقت پایدار، ذات الهی است. در نگاه عرفانی، این آیه فقط درباره مرگ نیست؛ بلکه درباره فانی بودن غرور، تعلقات و هویت‌های ظاهری انسان نیز سخن می‌گوید. پیام اصلی آیه این است که انسان نباید تمام وجود خود را به چیزهای موقتی گره بزند، بلکه باید به دنبال معنا، آگاهی، عشق و ارزش‌های عمیق‌تر در زندگی باشد.
اگر ما این موضوع را درک کنیم ، از بسیاری حسادت ها ، تعلقات ، تکبر ها، دروغ ها و تلاش های ظاهری کاسته میشود و ما "انسان" می‌شویم.

در ویرگول بیشتر صحبت کرده ام که اگر فانی هستیم چرا باید تلاش کنیم ؟

https://vrgl.ir/jYTXy

وقتی مهاجم قبض هوش مصنوعی را به قربانی می‌دهد

با گسترش حملات مبتنی بر هوش مصنوعی، شاید در آینده مهاجمان دیگر حتی نیاز نداشته باشند زیرساخت پردازشی یا مدل‌های سنگین خودشان را اجرا کنند. ایده‌ای که برخی مانند دیوید بیانکو آن را 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 را جدی می‌گیرند.

بررسی سرعت در SOC

مقوله Red Teaming یکی از مؤثرترین روش‌ها برای افزایش بلوغ SOC و بهبود سرعت کشف تهدیدات است. بسیاری از SOCها دارای Rule و Alert هستند، اما تنها در زمان شبیه‌سازی حملات واقعی مشخص می‌شود که Detectionها تا چه حد کارآمدند. Red Team با اجرای تکنیک‌های واقعی مهاجمان، ضعف‌های Visibility، کمبود Telemetry، ضعف Correlation و Blind Spotهای سازمان را آشکار می‌کند. این فرآیند باعث بهبود Detection Engineering، کاهش False Negative و افزایش دقت Threat Hunting می‌شود. همچنین تحلیلگران SOC با مشاهده رفتار واقعی مهاجم، درک عمیق‌تری از Attack Chain، رفتارهای مشکوک و روش‌های سریع‌تر شناسایی و پاسخ به حوادث پیدا می‌کنند.

در روز دوشنبه در ایسمینار از تجربه ۱۵ سال کار فنی بنده به نتایج خوبی خواهیم رسید .

👆دستورالعمل برپایی معماری Detection Engineering و مدیریت Detection مبتنی بر Git در SOC

تهیه شده توسط واحد MSSP شرکت هامون

جزئیات در لینک زیر

#MSSP #SOC #SOC_as_a_Service

لینک مقاله رو میتونید اینجا ببینید
https://vrgl.ir/F6Cif

پروژه جاری که با اسپلانک مدیریت میکنم رو سوئیچ کردم رو مبحث 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 های کشور

ابزار 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 اهمیت بسیار زیادی پیدا می‌کنند.

نکته ای در کانفیگ 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 #هامون