چرا درک روحیه و تفکر امنیتی برای برخی افراد دشوار است؟
مایندست ( تفکر و روحیه) امنیتی صرفاً مجموعه‌ای از دانش فنی یا ابزارهای کنترلی نیست، بلکه شیوه‌ای متفاوت از فکر کردن به سیستم‌ها، انسان‌ها و ریسک است. دشواری درک این مایندست از آنجا ناشی می‌شود که امنیت، برخلاف بسیاری از حوزه‌ها، برخلاف جریان طبیعی ذهن انسان حرکت می‌کند.
ذهن انسان عادت دارد به «کارکرد درست» فکر کند؛ اینکه یک سیستم چگونه طراحی شده تا به‌درستی عمل کند. اما ذهن امنیتی به‌دنبال کشف «نقطه شکست» است؛ اینکه سیستم چگونه، کِی و توسط چه کسی می‌تواند مورد سوءاستفاده قرار گیرد. این تغییر زاویه نگاه، برای بسیاری افراد ناخوشایند و حتی استرس‌زاست.
از سوی دیگر، امنیت با عدم قطعیت دائمی همراه است. در امنیت، پاسخ قطعی وجود ندارد؛ فقط احتمال، سناریو و ریسک وجود دارد. بسیاری از افراد ترجیح می‌دهند در چارچوب دستورالعمل‌های شفاف و خروجی‌های قابل اندازه‌گیری کار کنند، در حالی که موفقیت در امنیت اغلب به معنای «اتفاق نیفتادن» است؛ مفهومی که برای ذهن نتیجه‌محور رضایت‌بخش نیست.
مایندست و روحیه امنیتی همچنین مستلزم نوعی بی‌اعتمادی حرفه‌ای است؛ فرض بر این است که کاربر ممکن است خطا کند، سیستم ممکن است شکست بخورد و کنترل‌ها ممکن است دور زده شوند. این نگرش برای افرادی که به اعتماد پیش‌فرض عادت دارند، سخت و گاه منفی تلقی می‌شود.
در نهایت، درک امنیت بار مسئولیت ذهنی و اخلاقی به همراه دارد. کسی که ریسک را می‌بیند، دیگر نمی‌تواند آن را نادیده بگیرد. به همین دلیل، همه می‌توانند ابزار امنیتی یاد بگیرند، اما همه حاضر نیستند مایندست امنیتی را بپذیرند.
#آکادمی_روزبه
مرکز تخصصی آموزش و مهارت افزایی مدیر امنیت CISO
مایندست ( تفکر و روحیه) امنیتی صرفاً مجموعه‌ای از دانش فنی یا ابزارهای کنترلی نیست، بلکه شیوه‌ای متفاوت از فکر کردن به سیستم‌ها، انسان‌ها و ریسک است. دشواری درک این مایندست از آنجا ناشی می‌شود که امنیت، برخلاف بسیاری از حوزه‌ها، برخلاف جریان طبیعی ذهن انسان حرکت می‌کند.
ذهن انسان عادت دارد به «کارکرد درست» فکر کند؛ اینکه یک سیستم چگونه طراحی شده تا به‌درستی عمل کند. اما ذهن امنیتی به‌دنبال کشف «نقطه شکست» است؛ اینکه سیستم چگونه، کِی و توسط چه کسی می‌تواند مورد سوءاستفاده قرار گیرد. این تغییر زاویه نگاه، برای بسیاری افراد ناخوشایند و حتی استرس‌زاست.
از سوی دیگر، امنیت با عدم قطعیت دائمی همراه است. در امنیت، پاسخ قطعی وجود ندارد؛ فقط احتمال، سناریو و ریسک وجود دارد. بسیاری از افراد ترجیح می‌دهند در چارچوب دستورالعمل‌های شفاف و خروجی‌های قابل اندازه‌گیری کار کنند، در حالی که موفقیت در امنیت اغلب به معنای «اتفاق نیفتادن» است؛ مفهومی که برای ذهن نتیجه‌محور رضایت‌بخش نیست.
مایندست و روحیه امنیتی همچنین مستلزم نوعی بی‌اعتمادی حرفه‌ای است؛ فرض بر این است که کاربر ممکن است خطا کند، سیستم ممکن است شکست بخورد و کنترل‌ها ممکن است دور زده شوند. این نگرش برای افرادی که به اعتماد پیش‌فرض عادت دارند، سخت و گاه منفی تلقی می‌شود.
در نهایت، درک امنیت بار مسئولیت ذهنی و اخلاقی به همراه دارد. کسی که ریسک را می‌بیند، دیگر نمی‌تواند آن را نادیده بگیرد. به همین دلیل، همه می‌توانند ابزار امنیتی یاد بگیرند، اما همه حاضر نیستند مایندست امنیتی را بپذیرند.
#آکادمی_روزبه
مرکز تخصصی آموزش و مهارت افزایی مدیر امنیت CISO
❤5👍5
جایگاه فارنزیک در ISO/IEC 27001
در ISO 27001:2022، فارنزیک عمدتاً از سه منظر پوشش داده می‌شود:
آمادگی برای Incident Response، قابلیت جمع‌آوری شواهد قابل اتکا، و حفظ اعتبار حقوقی شواهد. این سه محور در Annex A پخش شده‌اند و اگر سازمان آن‌ها را درست پیاده نکند، هرگونه DFIR بعدی از نظر فنی و حقوقی ضعیف خواهد بود.
کنترل‌های کلیدی ISO 27001 مرتبط با فارنزیک
A.5.24 – Information security incident management planning and preparation
این کنترل پایه‌ای‌ترین ارتباط با فارنزیک را دارد. ISO انتظار دارد سازمان قبل از وقوع رخداد مشخص کرده باشد که در صورت Incident، شواهد چگونه جمع‌آوری، نگهداری و تحلیل می‌شوند. بدون این آمادگی، هر اقدامی بعد از رخداد می‌تواند Chain of Custody را بشکند. این کنترل نقطه اتصال ISO 27001 به DFIR واقعی است.
A.5.25 – Assessment and decision on information security events
در این کنترل، سازمان باید بتواند تشخیص دهد کدام Event یک Incident واقعی است. این دقیقاً همان جایی است که تحلیل Timeline، Correlation و Artifact Analysis وارد بازی می‌شود. اگر شواهد قابل تحلیل وجود نداشته باشد، این کنترل فقط روی کاغذ اجرا شده است.
A.5.26 – Response to information security incidents
پاسخ به رخداد بدون شواهد قابل اتکا، بیشتر شبیه واکنش احساسی است تا Incident Response. این کنترل به‌طور ضمنی نیازمند لاگ‌ها، Artifactها و داده‌هایی است که بعداً بتوان آن‌ها را به‌صورت فارنزیکی تحلیل کرد.
A.8.15 – Logging
این کنترل ستون فقرات فارنزیک است. ISO صراحتاً از Logging صحبت می‌کند، اما از دید فنی، منظور صرفاً فعال بودن لاگ نیست، بلکه کیفیت، جامعیت و هم‌زمانی زمانی لاگ‌هاست. بدون لاگ‌های مناسب، ابزارهایی مثل Plaso، SIEM Timeline یا Memory Forensics عملاً کور می‌شوند.
A.8.16 – Monitoring activities
مانیتورینگ مناسب باعث می‌شود نقاط شروع Timeline مشخص باشند. فارنزیک بدون knowing when to look، هزینه‌بر و ناقص می‌شود. این کنترل پیش‌نیاز کشف نقطه ورود و Scope Incident است.
A.8.17 – Clock synchronization
این کنترل اغلب دست‌کم گرفته می‌شود، اما از دید فارنزیک حیاتی است. اگر NTP و Time Sync درست نباشد، Timeline Analysis می‌تواند کاملاً گمراه‌کننده باشد. اختلاف چند دقیقه‌ای بین سیستم‌ها می‌تواند ترتیب واقعی حمله را مخدوش کند.
A.5.28 – Collection of evidence
این تنها کنترلی است که مستقیماً به Evidence اشاره می‌کند. ISO انتظار دارد شواهد به‌گونه‌ای جمع‌آوری شوند که از نظر حقوقی و انضباطی معتبر باشند. این کنترل مستقیماً به مفاهیمی مثل Chain of Custody، Integrity، Hashing و Repeatability گره خورده است و قلب فارنزیک رسمی محسوب می‌شود.
از دید ISO 27001، فارنزیک یک ابزار اختیاری نیست، بلکه نتیجه طبیعی اجرای صحیح مجموعه‌ای از کنترل‌ها است. اگر سازمانی بگوید «ISO 27001 داریم» اما لاگ مناسب، Time Sync، فرآیند Evidence Collection و Incident Handling تعریف‌شده نداشته باشد، در عمل قابلیت فارنزیک ندارد، حتی اگر گواهی هم گرفته باشد.
نکته مهمی که معمولاً Auditorها هم دچار خطا می‌شوند این است که ISO 27001 چارچوب قابلیت‌سازی است، نه دستورالعمل DFIR. ابزارهایی مثل SANS SIFT، Plaso یا Volatility زمانی ارزش دارند که این کنترل‌ها از قبل درست پیاده شده باشند.
#آکادمی_روزبه
مرکز تخصصی آموزش و مهارت افزایی مدیر امنیت CISO
در ISO 27001:2022، فارنزیک عمدتاً از سه منظر پوشش داده می‌شود:
آمادگی برای Incident Response، قابلیت جمع‌آوری شواهد قابل اتکا، و حفظ اعتبار حقوقی شواهد. این سه محور در Annex A پخش شده‌اند و اگر سازمان آن‌ها را درست پیاده نکند، هرگونه DFIR بعدی از نظر فنی و حقوقی ضعیف خواهد بود.
کنترل‌های کلیدی ISO 27001 مرتبط با فارنزیک
A.5.24 – Information security incident management planning and preparation
این کنترل پایه‌ای‌ترین ارتباط با فارنزیک را دارد. ISO انتظار دارد سازمان قبل از وقوع رخداد مشخص کرده باشد که در صورت Incident، شواهد چگونه جمع‌آوری، نگهداری و تحلیل می‌شوند. بدون این آمادگی، هر اقدامی بعد از رخداد می‌تواند Chain of Custody را بشکند. این کنترل نقطه اتصال ISO 27001 به DFIR واقعی است.
A.5.25 – Assessment and decision on information security events
در این کنترل، سازمان باید بتواند تشخیص دهد کدام Event یک Incident واقعی است. این دقیقاً همان جایی است که تحلیل Timeline، Correlation و Artifact Analysis وارد بازی می‌شود. اگر شواهد قابل تحلیل وجود نداشته باشد، این کنترل فقط روی کاغذ اجرا شده است.
A.5.26 – Response to information security incidents
پاسخ به رخداد بدون شواهد قابل اتکا، بیشتر شبیه واکنش احساسی است تا Incident Response. این کنترل به‌طور ضمنی نیازمند لاگ‌ها، Artifactها و داده‌هایی است که بعداً بتوان آن‌ها را به‌صورت فارنزیکی تحلیل کرد.
A.8.15 – Logging
این کنترل ستون فقرات فارنزیک است. ISO صراحتاً از Logging صحبت می‌کند، اما از دید فنی، منظور صرفاً فعال بودن لاگ نیست، بلکه کیفیت، جامعیت و هم‌زمانی زمانی لاگ‌هاست. بدون لاگ‌های مناسب، ابزارهایی مثل Plaso، SIEM Timeline یا Memory Forensics عملاً کور می‌شوند.
A.8.16 – Monitoring activities
مانیتورینگ مناسب باعث می‌شود نقاط شروع Timeline مشخص باشند. فارنزیک بدون knowing when to look، هزینه‌بر و ناقص می‌شود. این کنترل پیش‌نیاز کشف نقطه ورود و Scope Incident است.
A.8.17 – Clock synchronization
این کنترل اغلب دست‌کم گرفته می‌شود، اما از دید فارنزیک حیاتی است. اگر NTP و Time Sync درست نباشد، Timeline Analysis می‌تواند کاملاً گمراه‌کننده باشد. اختلاف چند دقیقه‌ای بین سیستم‌ها می‌تواند ترتیب واقعی حمله را مخدوش کند.
A.5.28 – Collection of evidence
این تنها کنترلی است که مستقیماً به Evidence اشاره می‌کند. ISO انتظار دارد شواهد به‌گونه‌ای جمع‌آوری شوند که از نظر حقوقی و انضباطی معتبر باشند. این کنترل مستقیماً به مفاهیمی مثل Chain of Custody، Integrity، Hashing و Repeatability گره خورده است و قلب فارنزیک رسمی محسوب می‌شود.
از دید ISO 27001، فارنزیک یک ابزار اختیاری نیست، بلکه نتیجه طبیعی اجرای صحیح مجموعه‌ای از کنترل‌ها است. اگر سازمانی بگوید «ISO 27001 داریم» اما لاگ مناسب، Time Sync، فرآیند Evidence Collection و Incident Handling تعریف‌شده نداشته باشد، در عمل قابلیت فارنزیک ندارد، حتی اگر گواهی هم گرفته باشد.
نکته مهمی که معمولاً Auditorها هم دچار خطا می‌شوند این است که ISO 27001 چارچوب قابلیت‌سازی است، نه دستورالعمل DFIR. ابزارهایی مثل SANS SIFT، Plaso یا Volatility زمانی ارزش دارند که این کنترل‌ها از قبل درست پیاده شده باشند.
#آکادمی_روزبه
مرکز تخصصی آموزش و مهارت افزایی مدیر امنیت CISO
👌5❤1
در شرایط عدم قطعیت چه کنیم ؟
** پاسخی بر مقاله مشکلات عدم قطعیت که در لینکدین نوشتم
آدم‌های حرفه‌ای حذف‌کنندهٔ عدم قطعیت نیستند؛ مدیرِ آن‌اند. تفاوتشان نه در دانستنِ بیشتر، بلکه در نحوهٔ رابطه‌شان با ندانستن است.
آن‌ها اول یک تمایز حیاتی را یاد می‌گیرند: «کنترل» با «قطعیت» یکی نیست. پزشک، خلبان یا تحلیلگر امنیت می‌داند که آینده مبهم است، اما می‌داند در هر لحظه چه چیزی در کنترل اوست. همین مرزبندی ساده، بخش بزرگی از فشار روانی را خنثی می‌کند. ذهن وقتی بداند کجا مسئول است و کجا نه، آرام‌تر تصمیم می‌گیرد.
دوم، آن‌ها به‌جای پاسخ قطعی، با سناریو کار می‌کنند. ذهن انسان از «یک آینده نامعلوم» می‌ترسد، اما با «چند آیندهٔ ممکن» کنار می‌آید. خلبان نمی‌گوید «نمی‌دانم چه می‌شود»، می‌گوید «اگر X شد، Y می‌کنم». تحلیلگر امنیت هم دنبال قطعیت نیست؛ دنبال احتمال + پیامد است. این یعنی تبدیل اضطراب مبهم به تصمیم عملی.
سوم، حرفه‌ای‌ها بار تصمیم را از ذهن به رویه و ابزار منتقل می‌کنند. چک‌لیست، پروتکل، Runbook، SOP دقیقاً برای همین ساخته شده‌اند: تا ذهن مجبور نباشد هر بار از صفر تصمیم بگیرد. این کار از فرسودگی شناختی جلوگیری می‌کند. به زبان ساده، آن‌ها مغزشان را برای «فکر کردن» نگه می‌دارند، نه برای «به یاد آوردن».
چهارم، آن‌ها رابطه‌شان با خطا را بازتعریف می‌کنند. برای فرد عادی، خطا یعنی شکست هویتی؛ برای حرفه‌ای، خطا یعنی داده. پزشک خوب از اشتباه می‌آموزد بدون اینکه خودش را با آن یکی بداند. این جداسازی «من» از «نتیجه» سپر روانی بسیار قدرتمندی است در برابر عدم قطعیت.
پنجم، و شاید عمیق‌ترین نکته: آن‌ها به‌جای امید به آرامش، به تحمل‌پذیری تکیه می‌کنند. یعنی انتظار ندارند اضطراب صفر شود؛ یاد می‌گیرند با وجود اضطراب کار درست را انجام دهند. این همان بلوغ حرفه‌ای است: عملِ مسئولانه در شرایط ناقص.
اگر بخواهم در یک جمله جمع‌بندی کنم، آدم‌های حرفه‌ای این را پذیرفته‌اند که
قطعیت پاداشِ کار نیست؛ ثباتِ در تصمیم‌گیری پاداش است.
#آکادمی_روزبه
** پاسخی بر مقاله مشکلات عدم قطعیت که در لینکدین نوشتم
آدم‌های حرفه‌ای حذف‌کنندهٔ عدم قطعیت نیستند؛ مدیرِ آن‌اند. تفاوتشان نه در دانستنِ بیشتر، بلکه در نحوهٔ رابطه‌شان با ندانستن است.
آن‌ها اول یک تمایز حیاتی را یاد می‌گیرند: «کنترل» با «قطعیت» یکی نیست. پزشک، خلبان یا تحلیلگر امنیت می‌داند که آینده مبهم است، اما می‌داند در هر لحظه چه چیزی در کنترل اوست. همین مرزبندی ساده، بخش بزرگی از فشار روانی را خنثی می‌کند. ذهن وقتی بداند کجا مسئول است و کجا نه، آرام‌تر تصمیم می‌گیرد.
دوم، آن‌ها به‌جای پاسخ قطعی، با سناریو کار می‌کنند. ذهن انسان از «یک آینده نامعلوم» می‌ترسد، اما با «چند آیندهٔ ممکن» کنار می‌آید. خلبان نمی‌گوید «نمی‌دانم چه می‌شود»، می‌گوید «اگر X شد، Y می‌کنم». تحلیلگر امنیت هم دنبال قطعیت نیست؛ دنبال احتمال + پیامد است. این یعنی تبدیل اضطراب مبهم به تصمیم عملی.
سوم، حرفه‌ای‌ها بار تصمیم را از ذهن به رویه و ابزار منتقل می‌کنند. چک‌لیست، پروتکل، Runbook، SOP دقیقاً برای همین ساخته شده‌اند: تا ذهن مجبور نباشد هر بار از صفر تصمیم بگیرد. این کار از فرسودگی شناختی جلوگیری می‌کند. به زبان ساده، آن‌ها مغزشان را برای «فکر کردن» نگه می‌دارند، نه برای «به یاد آوردن».
چهارم، آن‌ها رابطه‌شان با خطا را بازتعریف می‌کنند. برای فرد عادی، خطا یعنی شکست هویتی؛ برای حرفه‌ای، خطا یعنی داده. پزشک خوب از اشتباه می‌آموزد بدون اینکه خودش را با آن یکی بداند. این جداسازی «من» از «نتیجه» سپر روانی بسیار قدرتمندی است در برابر عدم قطعیت.
پنجم، و شاید عمیق‌ترین نکته: آن‌ها به‌جای امید به آرامش، به تحمل‌پذیری تکیه می‌کنند. یعنی انتظار ندارند اضطراب صفر شود؛ یاد می‌گیرند با وجود اضطراب کار درست را انجام دهند. این همان بلوغ حرفه‌ای است: عملِ مسئولانه در شرایط ناقص.
اگر بخواهم در یک جمله جمع‌بندی کنم، آدم‌های حرفه‌ای این را پذیرفته‌اند که
قطعیت پاداشِ کار نیست؛ ثباتِ در تصمیم‌گیری پاداش است.
#آکادمی_روزبه
👏5❤3
چطور مطالعه دروس تخصصی در این شرایط میتونه بهتون کمک کنه
این مساله در واقع از «مطالعه» عبور می‌کند و به «نقش شناختی و وجودی تخصص امنیت» می‌رسد. برای کسی که در حوزه امنیت کار می‌کند، مطالعه نه یک فعالیت جانبی است و نه صرفاً ابزار ارتقای شغلی؛ بلکه می‌تواند به یکی از معدود مکانیسم‌های سالمِ کنترل تنش، افسردگی، احساس ناامنی و عدم قطعیت تبدیل شود، البته فقط اگر آگاهانه و درست استفاده شود. اگر نادرست باشد، دقیقاً برعکس عمل می‌کند و فرسودگی را تشدید می‌کند.
ذهن متخصص امنیت به‌طور ذاتی برای دیدن تهدید تربیت شده است. این ذهن همیشه به‌دنبال نشانه، الگو، ضعف، سوءاستفاده و سناریوی شکست می‌گردد. در شرایط عادی، این ویژگی مزیت حرفه‌ای است، اما در شرایط ناامن اجتماعی و سیاسی، همین ویژگی می‌تواند به دام تبدیل شود؛ چون تهدیدهای بیرونی دیگر محدود، قابل اندازه‌گیری و قابل مهار نیستند. نتیجه این می‌شود که ذهن تحلیلگر، که نمی‌تواند «تحلیل نکند»، شروع می‌کند به تحلیل خودِ زندگی، آینده، کشور و سرنوشت، بدون اینکه داده‌ی کافی یا امکان مداخله داشته باشد. اینجاست که اضطراب مزمن و افسردگی شکل می‌گیرد.
مطالعه تخصصی امنیت، اگر عمیق و مفهومی باشد، یک کار بسیار مهم انجام می‌دهد: تهدید را از حالت مبهم و بی‌شکل به حالت مدل‌پذیر و ساخت‌یافته برمی‌گرداند. وقتی روی Threat Modeling، DFIR، Incident Analysis، Governance یا حتی معماری‌های امنیتی مطالعه می‌کنیم، مغز دوباره وارد جهانی می‌شود که در آن تهدید مرحله دارد، علت دارد، پیامد دارد و مهم‌تر از همه «قابل فهم» است. این کار مستقیماً احساس ناامنی را کاهش می‌دهد، نه به این دلیل که دنیا امن‌تر شده، بلکه چون ذهن دوباره حس می‌کند در برابر تهدید، کاملاً ناتوان نیست.
از نظر روانی، یکی از ریشه‌های اصلی افسردگی در متخصصان امنیت، احساس بی‌اثری است. ما می‌فهمیم چه اتفاقی در حال افتادن است، اما نمی‌توانیم تغییرش بدهیم. مطالعه تخصصی عمیق این چرخه را می‌شکند، چون به مغز فرصت «اثرگذاری شناختی» می‌دهد. وقتی یک حمله را دقیق‌تر از قبل می‌فهمیم، وقتی یک Control را بهتر تحلیل می‌کنیم، یا وقتی می‌بینیم چرا یک سازمان شکست خورده، مغز تجربه‌ی پیشرفت واقعی می‌کند. این پیشرفت شاید بیرونی نباشد، اما برای سیستم عصبی کاملاً واقعی است و جلوی فروپاشی روانی را می‌گیرد.
نکته مهم دیگر این است که مطالعه تخصصی، نشخوار ذهنی را به تحلیل واقعی تبدیل می‌کند. نشخوار یعنی فکر کردن مداوم بدون ساختار و بدون خروجی؛ تحلیل یعنی فکر کردن با چارچوب، فرضیه، وزن‌دهی شواهد و نتیجه‌گیری موقت. ذهن تحلیلگر اگر تحلیل نکند، نشخوار می‌کند. مطالعه درست، ذهن را مجبور می‌کند دوباره تحلیلگر باشد، نه قربانی افکار. این تفاوت کوچک، از نظر روانی حیاتی است.
در سطح عمیق‌تر، مطالعه تخصصی به حفظ هویت کمک می‌کند. در بحران‌های اجتماعی، بسیاری از هویت‌ها فرو می‌ریزند: شهروند بودن، آینده‌دار بودن، حتی امید داشتن. اما هویت حرفه‌ای اگر زنده بماند، می‌تواند ستون روان شود. وقتی شما هنوز می‌خوانید، می‌فهمید و تحلیل می‌کنید، به خودتون یادآوری می‌کنید که «من فقط محصول این شرایط نیستم؛ من توان فهم دارم». این برای متخصص امنیت بسیار مهم است، چون ارزش ما صرفاً در شغل یا درآمد نیست، بلکه در شیوه دیدن جهان است.
البته این فقط یک روی ماجراست. اگر نوع مطالعه اشتباه انتخاب شود، نتیجه معکوس خواهد داشت. غرق شدن در اخبار امنیتی، Breachهای پی‌درپی، فاجعه‌ها و مقایسه دائمی خود با بازار جهانی، ذهن را بیشتر در وضعیت تهدید نگه می‌دارد. چنین مطالعه‌ای اضطراب را تشدید می‌کند، چون به مغز پیام می‌دهد که «همه‌چیز در حال فروپاشی است و تو عقب مانده‌ای». مطالعه‌ای که کمک می‌کند، مطالعه‌ای است که عمق می‌دهد، نه هراس.
در نهایت، برای متخصص امنیت، مطالعه تخصصی در این شرایط نه فرار از واقعیت است و نه بی‌تفاوتی. این یک مکانیسم بقاست؛ راهی برای تبدیل ناامنی بیرونی به نظم درونی. شما با مطالعه، دنیا را عوض نمی‌کنید، اما اجازه نمی‌دهید آشوب دنیا، ساختار ذهنتان را نابود کند. و در شرایطی که بسیاری از چیزها از کنترل خارج است، حفظ سلامت ذهن تحلیلگر، خود یک دستاورد بزرگ و معنادار است.
#آکادمی_روزبه
این مساله در واقع از «مطالعه» عبور می‌کند و به «نقش شناختی و وجودی تخصص امنیت» می‌رسد. برای کسی که در حوزه امنیت کار می‌کند، مطالعه نه یک فعالیت جانبی است و نه صرفاً ابزار ارتقای شغلی؛ بلکه می‌تواند به یکی از معدود مکانیسم‌های سالمِ کنترل تنش، افسردگی، احساس ناامنی و عدم قطعیت تبدیل شود، البته فقط اگر آگاهانه و درست استفاده شود. اگر نادرست باشد، دقیقاً برعکس عمل می‌کند و فرسودگی را تشدید می‌کند.
ذهن متخصص امنیت به‌طور ذاتی برای دیدن تهدید تربیت شده است. این ذهن همیشه به‌دنبال نشانه، الگو، ضعف، سوءاستفاده و سناریوی شکست می‌گردد. در شرایط عادی، این ویژگی مزیت حرفه‌ای است، اما در شرایط ناامن اجتماعی و سیاسی، همین ویژگی می‌تواند به دام تبدیل شود؛ چون تهدیدهای بیرونی دیگر محدود، قابل اندازه‌گیری و قابل مهار نیستند. نتیجه این می‌شود که ذهن تحلیلگر، که نمی‌تواند «تحلیل نکند»، شروع می‌کند به تحلیل خودِ زندگی، آینده، کشور و سرنوشت، بدون اینکه داده‌ی کافی یا امکان مداخله داشته باشد. اینجاست که اضطراب مزمن و افسردگی شکل می‌گیرد.
مطالعه تخصصی امنیت، اگر عمیق و مفهومی باشد، یک کار بسیار مهم انجام می‌دهد: تهدید را از حالت مبهم و بی‌شکل به حالت مدل‌پذیر و ساخت‌یافته برمی‌گرداند. وقتی روی Threat Modeling، DFIR، Incident Analysis، Governance یا حتی معماری‌های امنیتی مطالعه می‌کنیم، مغز دوباره وارد جهانی می‌شود که در آن تهدید مرحله دارد، علت دارد، پیامد دارد و مهم‌تر از همه «قابل فهم» است. این کار مستقیماً احساس ناامنی را کاهش می‌دهد، نه به این دلیل که دنیا امن‌تر شده، بلکه چون ذهن دوباره حس می‌کند در برابر تهدید، کاملاً ناتوان نیست.
از نظر روانی، یکی از ریشه‌های اصلی افسردگی در متخصصان امنیت، احساس بی‌اثری است. ما می‌فهمیم چه اتفاقی در حال افتادن است، اما نمی‌توانیم تغییرش بدهیم. مطالعه تخصصی عمیق این چرخه را می‌شکند، چون به مغز فرصت «اثرگذاری شناختی» می‌دهد. وقتی یک حمله را دقیق‌تر از قبل می‌فهمیم، وقتی یک Control را بهتر تحلیل می‌کنیم، یا وقتی می‌بینیم چرا یک سازمان شکست خورده، مغز تجربه‌ی پیشرفت واقعی می‌کند. این پیشرفت شاید بیرونی نباشد، اما برای سیستم عصبی کاملاً واقعی است و جلوی فروپاشی روانی را می‌گیرد.
نکته مهم دیگر این است که مطالعه تخصصی، نشخوار ذهنی را به تحلیل واقعی تبدیل می‌کند. نشخوار یعنی فکر کردن مداوم بدون ساختار و بدون خروجی؛ تحلیل یعنی فکر کردن با چارچوب، فرضیه، وزن‌دهی شواهد و نتیجه‌گیری موقت. ذهن تحلیلگر اگر تحلیل نکند، نشخوار می‌کند. مطالعه درست، ذهن را مجبور می‌کند دوباره تحلیلگر باشد، نه قربانی افکار. این تفاوت کوچک، از نظر روانی حیاتی است.
در سطح عمیق‌تر، مطالعه تخصصی به حفظ هویت کمک می‌کند. در بحران‌های اجتماعی، بسیاری از هویت‌ها فرو می‌ریزند: شهروند بودن، آینده‌دار بودن، حتی امید داشتن. اما هویت حرفه‌ای اگر زنده بماند، می‌تواند ستون روان شود. وقتی شما هنوز می‌خوانید، می‌فهمید و تحلیل می‌کنید، به خودتون یادآوری می‌کنید که «من فقط محصول این شرایط نیستم؛ من توان فهم دارم». این برای متخصص امنیت بسیار مهم است، چون ارزش ما صرفاً در شغل یا درآمد نیست، بلکه در شیوه دیدن جهان است.
البته این فقط یک روی ماجراست. اگر نوع مطالعه اشتباه انتخاب شود، نتیجه معکوس خواهد داشت. غرق شدن در اخبار امنیتی، Breachهای پی‌درپی، فاجعه‌ها و مقایسه دائمی خود با بازار جهانی، ذهن را بیشتر در وضعیت تهدید نگه می‌دارد. چنین مطالعه‌ای اضطراب را تشدید می‌کند، چون به مغز پیام می‌دهد که «همه‌چیز در حال فروپاشی است و تو عقب مانده‌ای». مطالعه‌ای که کمک می‌کند، مطالعه‌ای است که عمق می‌دهد، نه هراس.
در نهایت، برای متخصص امنیت، مطالعه تخصصی در این شرایط نه فرار از واقعیت است و نه بی‌تفاوتی. این یک مکانیسم بقاست؛ راهی برای تبدیل ناامنی بیرونی به نظم درونی. شما با مطالعه، دنیا را عوض نمی‌کنید، اما اجازه نمی‌دهید آشوب دنیا، ساختار ذهنتان را نابود کند. و در شرایطی که بسیاری از چیزها از کنترل خارج است، حفظ سلامت ذهن تحلیلگر، خود یک دستاورد بزرگ و معنادار است.
#آکادمی_روزبه
❤11
عملیات OPSEC در سازمان بسیار مهم است . OPSEC باید در چارچوب مدیریت ریسک سازمانی تعریف شود، نه به‌عنوان فعالیتی جداگانه. مدیریت ریسک با شناسایی دارایی‌ها، تهدیدات و تعیین سطح ریسک، مبنای تصمیم‌گیری امنیتی را فراهم می‌کند و در مرحله «برخورد با ریسک» مشخص می‌شود چه کنترل‌هایی لازم است. بسیاری از تهدیدات از طریق جمع‌آوری تدریجی اطلاعات و نشانه‌های عملیاتی شکل می‌گیرند. در اینجا OPSEC به‌عنوان کنترلی برای جلوگیری از افشای ناخواسته اطلاعات حساس وارد عمل می‌شود. این یکپارچگی باعث شفافیت مدیریتی، تخصیص منطقی منابع، تعریف شاخص‌های قابل اندازه‌گیری و رویکردی پیش‌دستانه در برابر تهدیدات هدفمند می‌شود.
متن کامل در ویرگول
https://vrgl.ir/Api8q
متن کامل در ویرگول
https://vrgl.ir/Api8q
❤5
#درس_مدیریت
تو روان‌شناسی یه اصطلاحی داریم به اسم «توهم کنترل»
یعنی وقتی اوضاع ناامنه، آدم‌ها شروع می‌کنن به گیر دادن به جزئیات کوچیک. و چون ذهن طاقت بی‌قدرتی رو نداره. پس میرن دنبال چیزایی که بتونن روشون اثر بذارن:
بحث کردن، نصیحت کردن بقیه، گیر دادن به رفتارای دیگران!
تو روان‌شناسی یه اصطلاحی داریم به اسم «توهم کنترل»
یعنی وقتی اوضاع ناامنه، آدم‌ها شروع می‌کنن به گیر دادن به جزئیات کوچیک. و چون ذهن طاقت بی‌قدرتی رو نداره. پس میرن دنبال چیزایی که بتونن روشون اثر بذارن:
بحث کردن، نصیحت کردن بقیه، گیر دادن به رفتارای دیگران!
❤11
در SOC که راه می اندازی یک پاشنه آشیل ، False Positive است که نرخ بالای اون میتونه دمار از روزگار شما دربیاره و باعث بشه عملا SOC کارایی نداشته باشه .
مجموعه ای از تجربیاتم در این حوزه برای کاهش False Positive که میتونه SOC شما رو چابک کنه در مقاله زیر نوشتم امیدوارم به کارتون بیاد و شما هم تجربتون رو به اشتراک بگذارید.
با احترام
https://vrgl.ir/GYUZK
مجموعه ای از تجربیاتم در این حوزه برای کاهش False Positive که میتونه SOC شما رو چابک کنه در مقاله زیر نوشتم امیدوارم به کارتون بیاد و شما هم تجربتون رو به اشتراک بگذارید.
با احترام
https://vrgl.ir/GYUZK
❤3
استخدام
✅️مسلط به مانیتورینگ
✅️توانایی رول نویسی در فایروال
دریافتی خالص ۳۵ برای امسال
از اول فروردین حدود ۴۵ یا بیشتر
فول تایم حضوری تهران
ارسال رزومه به hr@haumoun.com
✅️مسلط به مانیتورینگ
✅️توانایی رول نویسی در فایروال
دریافتی خالص ۳۵ برای امسال
از اول فروردین حدود ۴۵ یا بیشتر
فول تایم حضوری تهران
ارسال رزومه به hr@haumoun.com
از تشخیص تا اختلال: یک ایده برای بازتعریف دفاع Endpoint
روزبه نوروزی
من معتقدم زمان آن رسیده که مدل دفاع Endpoint را بازتعریف کنیم. در بسیاری از سازمان‌ها هنوز امنیت بر مبنای «تشخیص و سپس واکنش» طراحی شده است؛ یعنی ابزار داده جمع می‌کند، هشدار تولید می‌شود و بعد از بررسی انسانی اقدام انجام می‌گیرد. اما واقعیت این است که مهاجمان امروزی، به‌ویژه در سناریوهای باج‌افزار، در بازه‌ای بسیار کوتاه می‌توانند از نفوذ اولیه به تخریب کامل برسند. در چنین شرایطی، صرف تشخیص کافی نیست.
ایده‌ای که مطرح می‌کنم، حرکت از «Detection-Centric Security» به سمت «Disruption-Driven Security» است. یعنی هدف اصلی سیستم دفاعی نباید فقط کشف حمله باشد، بلکه باید ایجاد اختلال فوری در زنجیره حمله باشد. Just in time IR. توقف فرآیند مخرب در لحظه اجرا، قطع ارتباط فرماندهی و کنترل، یا ایزوله‌سازی سریع Endpoint، می‌تواند هزینه و سرعت مهاجم را به‌شدت افزایش دهد.
در این مدل، اختلال خودکار در سطح Endpoint با تحلیل انسانی ترکیب می‌شود. ابزار در لحظه اقدام می‌کند و تیم امنیتی سپس با بررسی عمیق، علت ریشه‌ای، بهبود منطق‌های تشخیص و اصلاح سیاست‌ها را انجام می‌دهد. به‌این‌ترتیب، پاسخ امنیتی از «هشدار و رسیدگی» به «توقف و سپس تحلیل» تغییر می‌کند.
از نگاه من، بلوغ واقعی عملیات امنیتی زمانی شکل می‌گیرد که معیار موفقیت، نه تعداد هشدارهای مدیریت‌شده، بلکه سرعت و کیفیت اختلال در فعالیت مهاجم باشد.
چقدر در کشور ما توانستیم در این خصوص مانور بدهیم ؟
روزبه نوروزی
من معتقدم زمان آن رسیده که مدل دفاع Endpoint را بازتعریف کنیم. در بسیاری از سازمان‌ها هنوز امنیت بر مبنای «تشخیص و سپس واکنش» طراحی شده است؛ یعنی ابزار داده جمع می‌کند، هشدار تولید می‌شود و بعد از بررسی انسانی اقدام انجام می‌گیرد. اما واقعیت این است که مهاجمان امروزی، به‌ویژه در سناریوهای باج‌افزار، در بازه‌ای بسیار کوتاه می‌توانند از نفوذ اولیه به تخریب کامل برسند. در چنین شرایطی، صرف تشخیص کافی نیست.
ایده‌ای که مطرح می‌کنم، حرکت از «Detection-Centric Security» به سمت «Disruption-Driven Security» است. یعنی هدف اصلی سیستم دفاعی نباید فقط کشف حمله باشد، بلکه باید ایجاد اختلال فوری در زنجیره حمله باشد. Just in time IR. توقف فرآیند مخرب در لحظه اجرا، قطع ارتباط فرماندهی و کنترل، یا ایزوله‌سازی سریع Endpoint، می‌تواند هزینه و سرعت مهاجم را به‌شدت افزایش دهد.
در این مدل، اختلال خودکار در سطح Endpoint با تحلیل انسانی ترکیب می‌شود. ابزار در لحظه اقدام می‌کند و تیم امنیتی سپس با بررسی عمیق، علت ریشه‌ای، بهبود منطق‌های تشخیص و اصلاح سیاست‌ها را انجام می‌دهد. به‌این‌ترتیب، پاسخ امنیتی از «هشدار و رسیدگی» به «توقف و سپس تحلیل» تغییر می‌کند.
از نگاه من، بلوغ واقعی عملیات امنیتی زمانی شکل می‌گیرد که معیار موفقیت، نه تعداد هشدارهای مدیریت‌شده، بلکه سرعت و کیفیت اختلال در فعالیت مهاجم باشد.
چقدر در کشور ما توانستیم در این خصوص مانور بدهیم ؟
👏3❤2👍1
مروری بر فناوری رمزنگاری
از نسخهٔ 7.0 اندروید، سیستم File-Based Encryption (FBE) به‌عنوان استاندارد اصلی رمزگذاری معرفی شد؛ روشی که امنیت دستگاه را به‌صورت هوشمندانه و لایه‌مند افزایش می‌دهد. در این معماری، داده‌های ذخیره‌سازی به دو بخش مجزا تقسیم می‌شوند: Device Encrypted (DE) و Credential Encrypted (CE). این تفکیک باعث می‌شود هر دسته از اطلاعات در مناسب‌ترین زمان و با سطح دسترسی کنترل‌شده رمزگشایی شود.
ناحیهٔ DE شامل فایل‌های سیستمی و داده‌هایی است که دستگاه بلافاصله پس از روشن شدن، بدون نیاز به وارد کردن رمز، پین یا الگو، باید به آن‌ها دسترسی داشته باشد. این بخش امکان اجرای فرایندهای حیاتی مانند آلارم‌ها، سرویس‌های شبکه، و برخی عملیات پس‌زمینه را در لحظهٔ بوت فراهم می‌کند. به‌عبارت دیگر، DE پایه‌ای‌ترین عملکردهای سیستم را پیش از تأیید هویت کاربر تضمین می‌کند.
در مقابل، ناحیهٔ CE جایی است که تقریباً تمام داده‌های کاربر ذخیره می‌شود: پیام‌ها، عکس‌ها، دیتابیس‌های برنامه‌ها و هرگونه اطلاعات حساس و خصوصی. این بخش تنها زمانی رمزگشایی می‌شود که کاربر نخستین بار پس از بوت، اعتبار خود را وارد کند. به همین دلیل CE نقش مهمی در حفاظت از حریم خصوصی و جلوگیری از دسترسی غیرمجاز - حتی در صورت سرقت یا ری‌استارت دستگاه - دارد.
این معماری دوگانه، توازن دقیقی میان کارایی و امنیت ایجاد کرده و باعث شده اندروید در مدیریت داده‌های حساس، ساختاری منعطف‌تر و قابل‌اعتمادتر ارائه دهد.
از نسخهٔ 7.0 اندروید، سیستم File-Based Encryption (FBE) به‌عنوان استاندارد اصلی رمزگذاری معرفی شد؛ روشی که امنیت دستگاه را به‌صورت هوشمندانه و لایه‌مند افزایش می‌دهد. در این معماری، داده‌های ذخیره‌سازی به دو بخش مجزا تقسیم می‌شوند: Device Encrypted (DE) و Credential Encrypted (CE). این تفکیک باعث می‌شود هر دسته از اطلاعات در مناسب‌ترین زمان و با سطح دسترسی کنترل‌شده رمزگشایی شود.
ناحیهٔ DE شامل فایل‌های سیستمی و داده‌هایی است که دستگاه بلافاصله پس از روشن شدن، بدون نیاز به وارد کردن رمز، پین یا الگو، باید به آن‌ها دسترسی داشته باشد. این بخش امکان اجرای فرایندهای حیاتی مانند آلارم‌ها، سرویس‌های شبکه، و برخی عملیات پس‌زمینه را در لحظهٔ بوت فراهم می‌کند. به‌عبارت دیگر، DE پایه‌ای‌ترین عملکردهای سیستم را پیش از تأیید هویت کاربر تضمین می‌کند.
در مقابل، ناحیهٔ CE جایی است که تقریباً تمام داده‌های کاربر ذخیره می‌شود: پیام‌ها، عکس‌ها، دیتابیس‌های برنامه‌ها و هرگونه اطلاعات حساس و خصوصی. این بخش تنها زمانی رمزگشایی می‌شود که کاربر نخستین بار پس از بوت، اعتبار خود را وارد کند. به همین دلیل CE نقش مهمی در حفاظت از حریم خصوصی و جلوگیری از دسترسی غیرمجاز - حتی در صورت سرقت یا ری‌استارت دستگاه - دارد.
این معماری دوگانه، توازن دقیقی میان کارایی و امنیت ایجاد کرده و باعث شده اندروید در مدیریت داده‌های حساس، ساختاری منعطف‌تر و قابل‌اعتمادتر ارائه دهد.
❤2
روش‌های شناسایی PowerShell Stager در سیستم‌های ویندوز
مقوله PowerShell Stager یکی از پرکاربردترین ابزارهای مهاجمان برای آغاز حملات fileless است. Stager معمولاً یک اسکریپت بسیار کوچک است که وظیفه دارد مرحله‌ی بعدی بدافزار را از اینترنت دریافت و در حافظه اجرا کند. به‌دلیل ادغام عمیق PowerShell در ویندوز، تشخیص این رفتارها بدون مکانیزم‌های مناسب دشوار است. در ادامه، مهم‌ترین روش‌های شناسایی PowerShell Stager را بررسی می‌کنیم.
۱. بررسی لاگ‌های PowerShell (Event ID 4104)
قوی‌ترین ابزار تشخیص، فعال‌سازی Script Block Logging است. این ویژگی محتوای اسکریپت‌های اجراشده را ذخیره می‌کند.
نشانه‌های مشکوک در 4104:
- وجود دستورات مخرب مانند:
- درخواست وب:
-و 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، یکی از قوی‌ترین نشانه‌های حمله است.
مقوله 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، یکی از قوی‌ترین نشانه‌های حمله است.
❤3👍2
🔹 چرا ۶۷٪ از هشدارهای 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
و راه‌حل جدیدی به نام 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
GitHub
GitHub - iliasarmenakis/DeeperSplunk
Contribute to iliasarmenakis/DeeperSplunk development by creating an account on GitHub.
❤1
چارچوب 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#/
چارچوب 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، نیازمند بازتعریف این معیارها و ایجاد سازوکارهایی است که تحلیل عمیق، مبتنی بر شواهد و مقاوم در برابر فریب را ممکن و مقیاس‌پذیر کند.
در اغلب مراکز عملیات امنیت (SOC)، تریاژ هشدارها تحت فشار شدید زمان، حجم بالا و محدودیت منابع انجام می‌شود. نتیجه این شرایط، شکل‌گیری یک الگوی ذهنی غالب است: تحلیلگر به‌دنبال نخستین توضیح «منطقی و بی‌خطر» برای یک هشدار می‌گردد و در صورت یافتن آن، پرونده را می‌بندد. این رویکرد که می‌توان آن را «Benign-first» نامید، اگرچه از نظر عملیاتی کارآمد به نظر می‌رسد، اما یک ضعف بنیادی دارد: منطقی بودن، معادل واقعی بودن نیست. مهاجمان حرفه‌ای دقیقاً از همین شکاف استفاده می‌کنند و رفتار خود را طوری طراحی می‌کنند که در چارچوب توضیحات عادی و قابل‌قبول قرار گیرد.
در مقابل، رویکرد «Adversarial Thinking» قرار دارد؛ پارادایمی که به‌جای تلاش برای اثبات بی‌خطر بودن یک رویداد، از این فرض شروع می‌کند که «این می‌تواند یک حمله باشد». در این مدل، تحلیلگر یا سیستم می‌پرسد: اگر این یک سناریوی نفوذ باشد، چه شواهدی باید در لاگ‌ها، رفتار کاربر یا فعالیت سیستم مشاهده شود؟ سپس به‌صورت فعال به‌دنبال تأیید یا رد این فرضیه می‌گردد. این تغییر ساده در زاویه نگاه، تأثیر عمیقی بر کیفیت تشخیص دارد، زیرا فرآیند را از تأیید سریع به سمت بررسی عمیق و مبتنی بر شواهد سوق می‌دهد.
با این حال، این نوع تفکر در اغلب SOCها رایج نیست. یکی از دلایل اصلی، «اقتصاد عملیات» است. ابزارهایی مانند Splunk حجم عظیمی از هشدار تولید می‌کنند و تیم‌ها ناچارند با شاخص‌هایی مانند سرعت پاسخ و تعداد تیکت‌های بسته‌شده ارزیابی شوند. در چنین محیطی، تحلیل عمیق و مبتنی بر فرضیه، به‌عنوان یک لوکس تلقی می‌شود. علاوه بر این، بایاس‌های شناختی مانند «Confirmation Bias» باعث می‌شود تحلیلگر ناخودآگاه به‌دنبال شواهدی بگردد که فرض اولیه بی‌خطر بودن را تأیید کند، نه اینکه آن را به چالش بکشد.
مشکل دیگر، طراحی ابزارهاست. SIEMها برای جمع‌آوری، جستجو و همبستگی داده‌ها ساخته شده‌اند، نه برای تفکر خصمانه یا استدلال مبتنی بر فرضیه. به‌عبارت دیگر، آن‌ها داده می‌دهند، اما نمی‌گویند چگونه باید به آن‌ها شک کرد. در نتیجه، حتی تحلیل‌گران باتجربه نیز در جریان تریاژ روزمره، به‌سمت تصمیم‌گیری سریع و سطحی سوق داده می‌شوند.
در این میان، رویکردهایی مانند آنچه در DeeperSplunk مطرح شده، تلاش می‌کنند این شکاف را در سطح سیستم برطرف کنند. با استفاده از مدل‌هایی مانند Claude، این ابزارها فرآیند تریاژ را به‌صورت پیش‌فرض «خصمانه» طراحی می‌کنند؛ یعنی فرض اولیه را بر وجود حمله می‌گذارند و تنها در صورتی آن را رد می‌کنند که شواهد کافی برای بی‌خطر بودن ارائه شود. همچنین، با الزام به استناد به جستجوهای واقعی در SIEM، از تصمیم‌گیری‌های حدسی جلوگیری می‌کنند و امکان ممیزی (auditability) را افزایش می‌دهند.
در نهایت، مسئله اصلی صرفاً نبود مهارت یا دانش نیست، بلکه به طراحی فرآیندها و مشوق‌های عملیاتی بازمی‌گردد. تا زمانی که موفقیت در SOC بر اساس سرعت و حجم خروجی سنجیده شود، «توضیح قابل‌قبول» جای «حقیقت» را خواهد گرفت. حرکت به‌سوی Adversarial Thinking، نیازمند بازتعریف این معیارها و ایجاد سازوکارهایی است که تحلیل عمیق، مبتنی بر شواهد و مقاوم در برابر فریب را ممکن و مقیاس‌پذیر کند.
👏3❤1