در شرایط عدم قطعیت چه کنیم ؟

** پاسخی بر مقاله مشکلات عدم قطعیت که در لینکدین نوشتم


آدم‌های حرفه‌ای حذف‌کنندهٔ عدم قطعیت نیستند؛ مدیرِ آن‌اند. تفاوتشان نه در دانستنِ بیشتر، بلکه در نحوهٔ رابطه‌شان با ندانستن است.

آن‌ها اول یک تمایز حیاتی را یاد می‌گیرند: «کنترل» با «قطعیت» یکی نیست. پزشک، خلبان یا تحلیل‌گر امنیت می‌داند که آینده مبهم است، اما می‌داند در هر لحظه چه چیزی در کنترل اوست. همین مرزبندی ساده، بخش بزرگی از فشار روانی را خنثی می‌کند. ذهن وقتی بداند کجا مسئول است و کجا نه، آرام‌تر تصمیم می‌گیرد.

دوم، آن‌ها به‌جای پاسخ قطعی، با سناریو کار می‌کنند. ذهن انسان از «یک آینده نامعلوم» می‌ترسد، اما با «چند آیندهٔ ممکن» کنار می‌آید. خلبان نمی‌گوید «نمی‌دانم چه می‌شود»، می‌گوید «اگر X شد، Y می‌کنم». تحلیل‌گر امنیت هم دنبال قطعیت نیست؛ دنبال احتمال + پیامد است. این یعنی تبدیل اضطراب مبهم به تصمیم عملی.

سوم، حرفه‌ای‌ها بار تصمیم را از ذهن به رویه و ابزار منتقل می‌کنند. چک‌لیست، پروتکل، Runbook، SOP دقیقاً برای همین ساخته شده‌اند: تا ذهن مجبور نباشد هر بار از صفر تصمیم بگیرد. این کار از فرسودگی شناختی جلوگیری می‌کند. به زبان ساده، آن‌ها مغزشان را برای «فکر کردن» نگه می‌دارند، نه برای «به یاد آوردن».

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

پنجم، و شاید عمیق‌ترین نکته: آن‌ها به‌جای امید به آرامش، به تحمل‌پذیری تکیه می‌کنند. یعنی انتظار ندارند اضطراب صفر شود؛ یاد می‌گیرند با وجود اضطراب کار درست را انجام دهند. این همان بلوغ حرفه‌ای است: عملِ مسئولانه در شرایط ناقص.

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



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

چطور مطالعه دروس تخصصی در این شرایط میتونه بهتون کمک کنه


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

ذهن متخصص امنیت به‌طور ذاتی برای دیدن تهدید تربیت شده است. این ذهن همیشه به‌دنبال نشانه، الگو، ضعف، سوءاستفاده و سناریوی شکست می‌گردد. در شرایط عادی، این ویژگی مزیت حرفه‌ای است، اما در شرایط ناامن اجتماعی و سیاسی، همین ویژگی می‌تواند به دام تبدیل شود؛ چون تهدیدهای بیرونی دیگر محدود، قابل اندازه‌گیری و قابل مهار نیستند. نتیجه این می‌شود که ذهن تحلیلگر، که نمی‌تواند «تحلیل نکند»، شروع می‌کند به تحلیل خودِ زندگی، آینده، کشور و سرنوشت، بدون اینکه داده‌ی کافی یا امکان مداخله داشته باشد. این‌جاست که اضطراب مزمن و افسردگی شکل می‌گیرد.

مطالعه تخصصی امنیت، اگر عمیق و مفهومی باشد، یک کار بسیار مهم انجام می‌دهد: تهدید را از حالت مبهم و بی‌شکل به حالت مدل‌پذیر و ساخت‌یافته برمی‌گرداند. وقتی روی Threat Modeling، DFIR، Incident Analysis، Governance یا حتی معماری‌های امنیتی مطالعه می‌کنیم، مغز دوباره وارد جهانی می‌شود که در آن تهدید مرحله دارد، علت دارد، پیامد دارد و مهم‌تر از همه «قابل فهم» است. این کار مستقیماً احساس ناامنی را کاهش می‌دهد، نه به این دلیل که دنیا امن‌تر شده، بلکه چون ذهن دوباره حس می‌کند در برابر تهدید، کاملاً ناتوان نیست.

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

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

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

البته این فقط یک روی ماجراست. اگر نوع مطالعه اشتباه انتخاب شود، نتیجه معکوس خواهد داشت. غرق شدن در اخبار امنیتی، Breachهای پی‌درپی، فاجعه‌ها و مقایسه دائمی خود با بازار جهانی، ذهن را بیشتر در وضعیت تهدید نگه می‌دارد. چنین مطالعه‌ای اضطراب را تشدید می‌کند، چون به مغز پیام می‌دهد که «همه‌چیز در حال فروپاشی است و تو عقب مانده‌ای». مطالعه‌ای که کمک می‌کند، مطالعه‌ای است که عمق می‌دهد، نه هراس.

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


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

رهیافت‌های امنیت سایبری اتحادیه اروپا

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

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





متن کامل در ویرگول





https://vrgl.ir/Api8q

#درس_مدیریت

تو روان‌شناسی یه اصطلاحی داریم به اسم «توهم کنترل»

یعنی وقتی اوضاع ناامنه، آدم‌ها شروع می‌کنن به گیر دادن به جزئیات کوچیک. و چون ذهن طاقت بی‌قدرتی رو نداره. پس میرن دنبال چیزایی که بتونن روشون اثر بذارن:
بحث کردن، نصیحت کردن بقیه، گیر دادن به رفتارای دیگران!

در SOC که راه می اندازی یک پاشنه آشیل ، False Positive است که نرخ بالای اون میتونه دمار از روزگار شما دربیاره و باعث بشه عملا SOC کارایی نداشته باشه .

مجموعه ای از تجربیاتم در این حوزه برای کاهش False Positive که میتونه SOC شما رو چابک کنه در مقاله زیر نوشتم امیدوارم به کارتون بیاد و شما هم تجربتون رو به اشتراک بگذارید.

با احترام

https://vrgl.ir/GYUZK

استخدام

✅️مسلط به مانیتورینگ
✅️توانایی رول نویسی در فایروال


دریافتی خالص ۳۵ برای امسال
از اول فروردین حدود ۴۵ یا بیشتر

فول تایم حضوری تهران

ارسال رزومه به hr@haumoun.com

از تشخیص تا اختلال: یک ایده برای بازتعریف دفاع Endpoint

روزبه نوروزی


من معتقدم زمان آن رسیده که مدل دفاع Endpoint را بازتعریف کنیم. در بسیاری از سازمان‌ها هنوز امنیت بر مبنای «تشخیص و سپس واکنش» طراحی شده است؛ یعنی ابزار داده جمع می‌کند، هشدار تولید می‌شود و بعد از بررسی انسانی اقدام انجام می‌گیرد. اما واقعیت این است که مهاجمان امروزی، به‌ویژه در سناریوهای باج‌افزار، در بازه‌ای بسیار کوتاه می‌توانند از نفوذ اولیه به تخریب کامل برسند. در چنین شرایطی، صرف تشخیص کافی نیست.
ایده‌ای که مطرح می‌کنم، حرکت از «Detection-Centric Security» به سمت «Disruption-Driven Security» است. یعنی هدف اصلی سیستم دفاعی نباید فقط کشف حمله باشد، بلکه باید ایجاد اختلال فوری در زنجیره حمله باشد. Just in time IR. توقف فرآیند مخرب در لحظه اجرا، قطع ارتباط فرماندهی و کنترل، یا ایزوله‌سازی سریع Endpoint، می‌تواند هزینه و سرعت مهاجم را به‌شدت افزایش دهد.
در این مدل، اختلال خودکار در سطح Endpoint با تحلیل انسانی ترکیب می‌شود. ابزار در لحظه اقدام می‌کند و تیم امنیتی سپس با بررسی عمیق، علت ریشه‌ای، بهبود منطق‌های تشخیص و اصلاح سیاست‌ها را انجام می‌دهد. به‌این‌ترتیب، پاسخ امنیتی از «هشدار و رسیدگی» به «توقف و سپس تحلیل» تغییر می‌کند.

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

چقدر در کشور ما توانستیم در این خصوص مانور بدهیم ؟

09902857290

مروری بر فناوری رمزنگاری


از نسخهٔ 7.0 اندروید، سیستم File-Based Encryption (FBE) به‌عنوان استاندارد اصلی رمزگذاری معرفی شد؛ روشی که امنیت دستگاه را به‌صورت هوشمندانه و لایه‌مند افزایش می‌دهد. در این معماری، داده‌های ذخیره‌سازی به دو بخش مجزا تقسیم می‌شوند: Device Encrypted (DE) و Credential Encrypted (CE). این تفکیک باعث می‌شود هر دسته از اطلاعات در مناسب‌ترین زمان و با سطح دسترسی کنترل‌شده رمزگشایی شود.

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

در مقابل، ناحیهٔ CE جایی است که تقریباً تمام داده‌های کاربر ذخیره می‌شود: پیام‌ها، عکس‌ها، دیتابیس‌های برنامه‌ها و هرگونه اطلاعات حساس و خصوصی. این بخش تنها زمانی رمزگشایی می‌شود که کاربر نخستین بار پس از بوت، اعتبار خود را وارد کند. به همین دلیل CE نقش مهمی در حفاظت از حریم خصوصی و جلوگیری از دسترسی غیرمجاز - حتی در صورت سرقت یا ری‌استارت دستگاه - دارد.

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

روش‌های شناسایی PowerShell Stager در سیستم‌های ویندوز

مقوله PowerShell Stager یکی از پرکاربردترین ابزارهای مهاجمان برای آغاز حملات fileless است. Stager معمولاً یک اسکریپت بسیار کوچک است که وظیفه دارد مرحله‌ی بعدی بدافزار را از اینترنت دریافت و در حافظه اجرا کند. به‌دلیل ادغام عمیق PowerShell در ویندوز، تشخیص این رفتارها بدون مکانیزم‌های مناسب دشوار است. در ادامه، مهم‌ترین روش‌های شناسایی PowerShell Stager را بررسی می‌کنیم.


۱. بررسی لاگ‌های PowerShell (Event ID 4104)
قوی‌ترین ابزار تشخیص، فعال‌سازی Script Block Logging است. این ویژگی محتوای اسکریپت‌های اجراشده را ذخیره می‌کند.

نشانه‌های مشکوک در 4104:
- وجود دستورات مخرب مانند: IEX, Invoke-Expression
- درخواست وب: DownloadString, Invoke-WebRequest, Net.WebClient
-و Base64 مشکوک یا رشته‌های رمزگذاری‌شده 
- مبهم‌سازی (Obfuscation) مانند شکستن رشته‌ها با +, "|"

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


۲. تحلیل ساختار فرآیندها (Event ID 4688)
برای تشخیص Stager، بررسی اینکه چه برنامه‌ای PowerShell را اجرا کرده اهمیت بالایی دارد.

رفتارهای خطرناک:
- اجرای PowerShell توسط Word، Excel یا PDF Reader 
- اجرای PowerShell با پارامترهایی مانند:
  - وجود-nop (بدون پروفایل)
  - و-w hidden (اجرای مخفی)
  - و-enc (اسکریپت Base64 رمزگذاری‌شده)
- اجرای PowerShell بدون تعامل کاربر (روند خودکار پس‌زمینه)

این رفتارها غالباً با فیشینگ و ماکروهای مخرب همراه هستند.


۳. تحلیل ترافیک شبکه
خودPowerShell معمولاً به اینترنت وصل نمی‌شود، بنابراین هرگونه ارتباط غیرعادی باید بررسی شود.

نشانه‌های شناسایی:
- اتصال به IPهای ناشناس یا خام (بدون دامنه)
- ارتباط در پورت‌های غیررایج مثل 4443، 8080
- دانلود اسکریپت از URLهای کوتاه‌شده یا موقت
- وUser-Agent غیرعادی یا خالی

ترکیب این نشانه‌ها با لاگ‌های PowerShell اغلب وجود Stager را اثبات می‌کند.


۴. تشخیص رفتارهای Fileless در حافظه
از آنجا که Stager معمولاً فایل ایجاد نمی‌کند، باید رفتار حافظه بررسی شود. این کار توسط EDR/XDR/Sysmon انجام می‌شود.

علائم مهم:
- اجرای کد در حافظه با Reflection یا Assembly.Load
- ایجاد Named Pipeهای مشکوک
- تزریق کد در فرآیندهای قانونی مثل explorer.exe

این نشانه‌ها وجود یک Payload ثانویه را تایید می‌کنند.


۵. شناسایی مبهم‌سازی (Obfuscation)
مهاجمان تقریباً همیشه stager را مبهم‌سازی می‌کنند تا از چشم آنتی‌ویروس فرار کند.

نمونه‌های رایج:
- استفاده از Base64 طولانی 
- تقسیم کد به قطعات کوچک 
- جایگزینی نام متغیرها با علامت‌ها یا کاراکترهای تصادفی 
- استفاده از کاراکترهای Unicode غیرمعمول

وجود این علائم در لاگ 4104 یا در فرآیندهای PowerShell، یکی از قوی‌ترین نشانه‌های حمله است.

🔹 چرا ۶۷٪ از هشدارهای SIEM بررسی نمی‌شوند؟
و راه‌حل جدیدی به نام DeeperSplunk چه می‌کند؟

تیم‌های SOC امروز بیش از همیشه با انبوهی از هشدارهای اشتباه (False Positive) روبه‌رو هستند. طبیعی است: وقتی هر هشدار می‌تواند ده‌ها توضیح بی‌خطر داشته باشد، تحلیل‌گر معمولاً اولین توضیح منطقی را انتخاب می‌کند و کار را تمام‌شده می‌داند.
اما مشکل اینجاست: منطقی بودن یعنی قابل‌قبول بودن، نه الزاماً واقعی بودن. مهاجمان حرفه‌ای دقیقاً طراحی می‌کنند تا فعالیتشان بی‌خطر جلوه کند.

🔍راهکار DeeperSplunk چیست؟

راهکار DeeperSplunk یک پروژه متن‌باز است که تلاش می‌کند این مشکل را حل کند. این ابزار یک سرور MCP ارائه می‌دهد که به مدل Claude اجازه می‌دهد تریاژ خصمانه (Adversarial Triage) در برابر Splunk انجام دهد.

به زبان ساده:
برای هر هشدار، عامل هوشمند تلاش می‌کند ثابت کند مهاجم در حال برنده شدن است.
فقط وقتی تبرئه می‌کند که شواهد، فرضیه حمله را فعالانه رد کنند.


🔧 چه چیزی DeeperSplunk را متفاوت می‌کند؟

سه نوآوری کلیدی در طراحی آن وجود دارد:

1) استناد اجباری به شواهد
عامل نمی‌تواند ادعایی مطرح کند که خودش درباره آن جستجو نکرده باشد.
هر نتیجه باید به یک جستجوی واقعی در همان جلسه اشاره کند.

2) ارتقای خودکار بر اساس اعتماد (Confidence‑Based Auto‑Escalation)
اگر مدل برای رأی‌گیری (TP/FP) اعتماد کافی نداشته باشد، نتیجه فوراً به وضعیت
NEEDS_HUMAN_REVIEW
منتقل می‌شود.
هیچ رأیی بر اساس حدس صادر نمی‌شود.

3) حافظه رأی مبتنی بر SQLite
تمام تصمیم‌ها و بازبینی‌های انسانی ذخیره می‌شود تا هشدارهای آینده با موارد مشابه قبلی مقایسه شوند.


🧩 ویژگی‌های فنی و هدف پروژه

- قابل اجرا به‌صورت لوکال
- بر پایه Python 3.10
- دارای مجوز MIT
- طراحی‌شده به‌عنوان یک جایگزین متن‌باز برای ابزارهای تجاری مانند
D3 Morpheus و Cortex XSIAM

لینک پروژه:
https://github.com/iliasarmenakis/DeeperSplunk

چارچوب MITRE F3 برای مقابله با کلاهبرداری

چارچوب MITRE Fight Fraud Framework (F3) که توسط MITRE و مرکز Center for Threat-Informed Defense توسعه یافته، یک مدل ساختاریافته برای تحلیل، شناسایی و مقابله با کلاهبرداری‌های مالی در بسترهای دیجیتال است. این چارچوب با الهام از MITRE ATT&CK طراحی شده، اما تمرکز آن به‌جای نفوذ سایبری صرف، بر زنجیره کامل حملات Fraud از مرحله شناسایی تا برداشت مالی (cash-out) است.

در F3، رفتار مهاجمان بر اساس تاکتیک‌ها و تکنیک‌ها (TTPs) مدل‌سازی می‌شود. تاکتیک‌هایی مانند Reconnaissance، Initial Access و Defense Evasion مشابه دنیای سایبری هستند، اما مفاهیم کلیدی جدیدی مانند Positioning (ایجاد موقعیت برای سوءاستفاده مالی) و Monetization (تبدیل دسترسی به پول) اضافه شده‌اند. این رویکرد کمک می‌کند تا شکاف بین تیم‌های امنیت سایبری (SOC/DFIR) و تیم‌های کشف تقلب مالی برطرف شود.

اهمیت F3 در ایجاد یک زبان مشترک عملیاتی است که امکان همبستگی بین لاگ‌های فنی و رخدادهای مالی را فراهم می‌کند. در نتیجه، سازمان‌ها می‌توانند از حالت واکنشی خارج شده و با طراحی Use Caseهای دقیق‌تر، تهدیدات Fraud را پیش از تحقق زیان مالی شناسایی و مهار کنند.


https://ctid.mitre.org/fraud#/

از «توضیح قابل‌قبول» تا «فرض حمله»: شکاف پنهان در تریاژ SOC


در اغلب مراکز عملیات امنیت (SOC)، تریاژ هشدارها تحت فشار شدید زمان، حجم بالا و محدودیت منابع انجام می‌شود. نتیجه این شرایط، شکل‌گیری یک الگوی ذهنی غالب است: تحلیل‌گر به‌دنبال نخستین توضیح «منطقی و بی‌خطر» برای یک هشدار می‌گردد و در صورت یافتن آن، پرونده را می‌بندد. این رویکرد که می‌توان آن را «Benign-first» نامید، اگرچه از نظر عملیاتی کارآمد به نظر می‌رسد، اما یک ضعف بنیادی دارد: منطقی بودن، معادل واقعی بودن نیست. مهاجمان حرفه‌ای دقیقاً از همین شکاف استفاده می‌کنند و رفتار خود را طوری طراحی می‌کنند که در چارچوب توضیحات عادی و قابل‌قبول قرار گیرد.
در مقابل، رویکرد «Adversarial Thinking» قرار دارد؛ پارادایمی که به‌جای تلاش برای اثبات بی‌خطر بودن یک رویداد، از این فرض شروع می‌کند که «این می‌تواند یک حمله باشد». در این مدل، تحلیل‌گر یا سیستم می‌پرسد: اگر این یک سناریوی نفوذ باشد، چه شواهدی باید در لاگ‌ها، رفتار کاربر یا فعالیت سیستم مشاهده شود؟ سپس به‌صورت فعال به‌دنبال تأیید یا رد این فرضیه می‌گردد. این تغییر ساده در زاویه نگاه، تأثیر عمیقی بر کیفیت تشخیص دارد، زیرا فرآیند را از تأیید سریع به سمت بررسی عمیق و مبتنی بر شواهد سوق می‌دهد.
با این حال، این نوع تفکر در اغلب SOCها رایج نیست. یکی از دلایل اصلی، «اقتصاد عملیات» است. ابزارهایی مانند Splunk حجم عظیمی از هشدار تولید می‌کنند و تیم‌ها ناچارند با شاخص‌هایی مانند سرعت پاسخ و تعداد تیکت‌های بسته‌شده ارزیابی شوند. در چنین محیطی، تحلیل عمیق و مبتنی بر فرضیه، به‌عنوان یک لوکس تلقی می‌شود. علاوه بر این، بایاس‌های شناختی مانند «Confirmation Bias» باعث می‌شود تحلیل‌گر ناخودآگاه به‌دنبال شواهدی بگردد که فرض اولیه بی‌خطر بودن را تأیید کند، نه اینکه آن را به چالش بکشد.
مشکل دیگر، طراحی ابزارهاست. SIEMها برای جمع‌آوری، جستجو و همبستگی داده‌ها ساخته شده‌اند، نه برای تفکر خصمانه یا استدلال مبتنی بر فرضیه. به‌عبارت دیگر، آن‌ها داده می‌دهند، اما نمی‌گویند چگونه باید به آن‌ها شک کرد. در نتیجه، حتی تحلیل‌گران باتجربه نیز در جریان تریاژ روزمره، به‌سمت تصمیم‌گیری سریع و سطحی سوق داده می‌شوند.
در این میان، رویکردهایی مانند آنچه در DeeperSplunk مطرح شده، تلاش می‌کنند این شکاف را در سطح سیستم برطرف کنند. با استفاده از مدل‌هایی مانند Claude، این ابزارها فرآیند تریاژ را به‌صورت پیش‌فرض «خصمانه» طراحی می‌کنند؛ یعنی فرض اولیه را بر وجود حمله می‌گذارند و تنها در صورتی آن را رد می‌کنند که شواهد کافی برای بی‌خطر بودن ارائه شود. همچنین، با الزام به استناد به جستجوهای واقعی در SIEM، از تصمیم‌گیری‌های حدسی جلوگیری می‌کنند و امکان ممیزی (auditability) را افزایش می‌دهند.
در نهایت، مسئله اصلی صرفاً نبود مهارت یا دانش نیست، بلکه به طراحی فرآیندها و مشوق‌های عملیاتی بازمی‌گردد. تا زمانی که موفقیت در SOC بر اساس سرعت و حجم خروجی سنجیده شود، «توضیح قابل‌قبول» جای «حقیقت» را خواهد گرفت. حرکت به‌سوی Adversarial Thinking، نیازمند بازتعریف این معیارها و ایجاد سازوکارهایی است که تحلیل عمیق، مبتنی بر شواهد و مقاوم در برابر فریب را ممکن و مقیاس‌پذیر کند.

گزارش VulnCheck Exploit Intelligence 2026 تحلیلی جامع از وضعیت آسیب‌پذیری‌ها و بهره‌برداری‌های امنیتی در سال 2025 ارائه می‌دهد و تلاش می‌کند فاصله میان حجم عظیم CVEها و واقعیت بهره‌برداری در دنیای واقعی را روشن کند. طبق داده‌ها، در سال 2025 بیش از 14,400 اکسپلویت شناسایی شده که 10,480 آسیب‌پذیری را هدف گرفته‌اند؛ با وجود این گستردگی، تنها حدود 1 درصد از CVEهای سال 2025 واقعاً در محیط عملیاتی مورد سوءاستفاده قرار گرفته‌اند. این نشان می‌دهد که تعداد بالا همیشه بیانگر ریسک واقعی نیست و اولویت‌بندی بر اساس شواهد بهره‌برداری اهمیت بیشتری دارد.

در سال 2025 تعداد 884 آسیب‌پذیری وارد فهرست KEV شده‌اند که نزدیک به نیمی از آن‌ها مربوط به همان سال بوده است؛ بنابراین مهاجمان به‌سرعت آسیب‌پذیری‌های جدید را weaponize می‌کنند. روندهای تهدید نشان می‌دهد که تعداد آسیب‌پذیری‌های مرتبط با باج‌افزار 25 درصد کاهش داشته، اما بیش از نیمی از آن‌ها حاصل بهره‌برداری روز صفر بوده‌اند. فعالیت گروه‌های APT نیز کاهش کلی داشته، اما گروه‌های منتسب به چین افزایش حضور داشته‌اند.

جمع‌بندی گزارش تأکید می‌کند که سازمان‌ها باید به‌جای تمرکز بر حجم CVEها، روی اطلاعات بهره‌برداری واقعی، سرعت واکنش، و تحلیل داده‌محور تمرکز کنند تا بتوانند ریسک‌های مؤثر را مدیریت کرده و از هزینه‌های بالای حملات جلوگیری کنند.

دوره آموزشی رایگان

https://xmcyber.com/exposure-management-course/?utm_source=csh&utm_medium=social&utm_content=emcourse

🎯 بحث Detection Logic حرفه‌ای: توازن میان هزینه و ریسک

در بسیاری از مراکز عملیات امنیت (SOC)، تمرکز بیش از حد بر کاهش False Positive (FP) به یک رویکرد غالب تبدیل شده است. این تمرکز، اگرچه با هدف کاهش فشار عملیاتی بر تحلیلگران انجام می‌شود، اما یک ریسک پنهان ایجاد می‌کند: افزایش احتمال False Negative (FN). در عمل، FP صرفاً به معنای هزینه عملیاتی بیشتر است، اما FN می‌تواند به یک breach واقعی منجر شود.

مسئله کلیدی این است که حذف کامل FP نه ممکن است و نه مطلوب. بسیاری از رفتارهای مخرب شباهت زیادی به فعالیت‌های عادی دارند و حذف این سیگنال‌ها به معنای از دست دادن دید نسبت به تهدیدات است. Detection Logic حرفه‌ای این واقعیت را می‌پذیرد و به‌جای حذف FP، آن‌ها را contextualize می‌کند.

در این رویکرد، هر alert در بستر اطلاعاتی گسترده‌تری تحلیل می‌شود: نوع کاربر، حساسیت سیستم، رفتارهای پیشین و ارتباط با سایر رویدادها. به این ترتیب، FPها به سیگنال‌هایی با وزن مشخص در یک مدل تصمیم‌گیری مبتنی بر ریسک تبدیل می‌شوند.

این نگرش با چارچوب‌هایی مانند MITRE ATT&CK هم‌راستا است، زیرا تمرکز آن بر رفتار مهاجم و زنجیره حمله است، نه صرفاً رویدادهای منفرد. در نهایت، SOC بالغ سیستمی است که به‌جای حذف نویز، آن را به دانش قابل تصمیم‌گیری تبدیل می‌کند.

#استخدام


فوری

برنامه نویس Microsoft Dynamics

برای توسعه پرتال مشتریان


فول تایم حضوری تهران
ارسال رزومه به hr@haumoun.com

لطفا برای دوستان بفرستید