محیط های کوبرنتیز و کانتینر در خیلی از سازمانها رها شده اند در سلسله مقالاتی خطراتی که متوجه این سازمانها هستند را بررسی میکنم

خطرات نبود EDR در محیط‌های Kubernetes

نبود EDR در محیط‌های Kubernetes یکی از شکاف‌های امنیتی رایج، اما بسیار پرریسک است؛ زیرا معماری Container‑Based با سرعت بالا، ماهیت Ephemeral و توزیع‌شده خود نقطه‌های کور زیادی ایجاد می‌کند. در چنین محیطی، نبود EDR باعث می‌شود بخش کلیدی از زنجیره تله‌متری و کنترل تهدید از بین برود. مهم‌ترین خطرات عبارت‌اند از:

1. عدم توانایی در شناسایی رفتارهای مخرب داخل Pod
حملات Runtime مانند اجرای Shell در کانتینر، تغییر مسیرهای فایل، اجرای ابزارهای مهاجم (curl/wget/nc) و سوءاستفاده از کتابخانه‌ها قابل مشاهده نیستند.

2. چشم‌پوشی کامل از حملات Drift Runtime

اگر یک کانتینر رفتار متفاوتی از Image پایه انجام دهد (مثل دانلود باینری جدید، ایجاد کانکشن غیرمعمول)، بدون EDR هیچ‌کس متوجه نمی‌شود.

3. ناتوانی در تشخیص حرکت جانبی (Lateral Movement) داخل کلاستر
مهاجم با دسترسی به یک Pod می‌تواند:
• به Kubelet دسترسی بگیرد
• وSecrets را استخراج کند
• به سرویس‌های مجاور Pivot کند
بدون اینکه SIEM یا NIDS چیزی ببیند.

4. عدم مشاهده تهدیدات مبتنی بر Node
اگر مهاجم از طریق Container Escape وارد Node شود، بدون EDR رفتارهای سیستم‌عاملی Node قابل مشاهده نیست و این یعنی Blind Spot کامل.

5. ریسک Exfiltration نامحسوس
کانتینر آلوده می‌تواند داده را به‌صورت Low‑and‑Slow خارج کند؛ معمولاً در Long Tail قرار می‌گیرد و شما دست خالی هستید .

6. وضعیت فاجعه‌بار در برابر APT و حملات Supply Chain
حملاتی مثل:
• آلوده شدن Base Image
• سوءاستفاده از کتابخانه آلوده
• بارگذاری Image از ریجستری جعلی
بدون EDR هیچ‌وقت در Runtime دیده نمی‌شوند.

7. چشم‌پوشی از Indicators of Attack (IoA)

لاگهای Kubernetes فقط فعالیت‌های Control Plane را نشان می‌دهند
ولی هیچ چیز درباره رفتار داخل Pod یا Node نمی‌گویند.

8. مشکل جدی در Incident Response
وقتی EDR نباشد:
• مساله Capture کردن Memory
• و Timeline ناقص
• فهم Pivot مهاجم تقریباً غیرممکن
یعنی Incident Response فقط «حدس» است، نه Investigation.


**امروزه به جای واژه EDR در محیط کوبرنتیز، بیشتر از ابزارهای Runtime Security یا CWPP (Cloud Workload Protection Platforms) استفاده می‌شود

مثالی از سه شاخصه در SOC

بیس لاین: کاربر X معمولا از IP ایران ساعت ۸ تا ۱۷ لاگین میکند

کشف آنومالی: کاربر ساعت ۳ صبح از روسیه لاگین کرده است

نقش KRI شاخصه ریسک:
کاربر X دارای سطح دسترسی حساس است پس ریسک بالا است

بسیاری از دوستان عامل سوم را درنظر نمی‌گیرند درصورتی که همین عامل نقش بسزایی در دقت و بهروه وری SOC دارد .

#اشتراک_دانش و #تجربه

سرفصل دوره مدیریت ارشد امنیت CISO
09902857290

یکی گفته بود این نوروزی اینقدر پست میگذاره ، کار هم میکنه ؟!!

گفتم فقط اینو بهش بگین:
اگر شغل امنیت برای شما یه اجباره ، برای نوروزی عشقه
اگر شما از شغلت راضی نیستی به حدی که نه تنها ساعت ۵ عصر امنیت رو فراموش میکنی بلکه در طول روز هم حواست بهش نیست ؛ اما نوروزی با امنیت زندگی میکنه ...عاشق شغلشه بطوریکه در مترو و اسنپ و شب و نیمه شب و کله صبح با امنیته

از همه مهمتر :
نوروزی یه معلمه
عاشق یادگیری و آموختن هست و براش اجباره به بقیه یاد بده ...پس تو و نوروزی فرق دارید!!



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



لذا بله من و اون فرق میکنیم

من میتونم روزی ۴ مقاله علاوه بر کارم بنویسم ولی اون هر روز احتمال داره از کار بیکار بشه چون از امنیت متنفره ، سر کار هیچی یاد نمیگیره هیچ آزمایشی انجام نمیده و هیچی نمیخونه !!

با احترام . تمام💫

بهینه‌سازی رول‌های سیگما با استفاده از Context-Aware Correlation مقوله ای که بسیاری از رول نویسان رعایت نمی‌کنند


در معماری‌های مدرن تشخیص تهدید، رول‌های سیگما نقشی کلیدی در استانداردسازی تشخیص در سطح SIEM ایفا می‌کنند. با این حال، بسیاری از رول‌های سنتی مبتنی بر تطبیق تک‌رویداد (Single-Event Matching) هستند و همین موضوع باعث تولید حجم بالایی از هشدارهای کاذب و از دست رفتن فعالیت‌های مهم می‌شود. راه‌حل مؤثر، حرکت از تطبیق ساده به سمت Context‑Aware Correlation است؛ مدلی که رویدادها را در یک چارچوب زمانی، کاربری و فرآیندی تحلیل می‌کند.

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

پیاده‌سازی این روش نیازمند ساختاردهی به پارامترهایی مانند Window زمانی، User Context، Process Lineage و Baseline رفتاری است. نتیجه نهایی: کاهش چشمگیر False Positiveها، ارتقای کیفیت Hunting و افزایش بلوغ عملیاتی SOC.


مثال :

یک مثال از یک الگوی اصلاح ، نه یک Signature عملیاتی را با هم بررسی میکنیم

مثال: بهبود یک رول با افزودن «زمینه رویداد»

وضعیت اولیه (ضعیف):

یک رول ساده می‌گوید اگر یک ابزار خط فرمان خاص اجرا شد : هشدار.

مشکل:
اگر این ابزار به صورت طبیعی توسط سیستم یا نرم‌افزارهای مجاز اجرا شود، کلی False Positive تولید می‌شود.


نسخه اصلاح‌شده با Context

به‌جای Match ساده روی "اجرای یک برنامه"، الگو را این‌گونه اصلاح می‌کنیم:

1. رخداد اجرا شدن ابزار X دیده شود
2. وParent Process آن در لیست فرآیندهای معتبری که قبلاً Baseline شده‌اند نباشد
3. همان User در پنجره زمانی کمتر از ۳۰ ثانیه، هیچ فعالیت مشابهی نداشته باشد
4. خط فرمان (Command Line) پارامتر غیرعادی داشته باشد (مثلاً یک Path نادیده)


تفسیر فنی
این مثال نشان می‌دهد که یک رول سیگما وقتی از تک‌رویداد به سمت بررسی «چه کسی، با چه Parent، در چه Context زمانی» حرکت کند، کیفیت تشخیص چند برابر بهتر می‌شود.


به‌جای اینکه رول فقط روی یک رویداد Match کند، آن را به الگوی چندرویدادی (Behavior Pattern) تبدیل می‌کنیم. این روش برای SIEM/EDR بهترین کیفیت نتیجه را می‌دهد.

مسئولیت حقوقی امنیت سایبری، آزمون نزدیکی، و تکلیف قانونی:
تحلیل راهبردی برای مدیران ارشد امنیت اطلاعات (CISO)

در زیست‌بوم دیجیتال امروز، سازمان‌ها با انتظارات فزایندهٔ قانونی و مقرراتی برای حفاظت از کاربران و ذی‌نفعان در برابر خسارات اقتصادی ناشی از حملات سایبری روبه‌رو هستند. با پیچیده‌تر شدن تهدیدات و وابستگی گستردهٔ جامعه به خدمات دیجیتال، دادگاه‌ها و رگولاتورها به اصول سنتی مسئولیت مدنی-به‌ویژه آزمون نزدیکی (Proximity) و تکلیف مراقبت (Duty of Care)-بازمی‌گردند تا تشخیص دهند یک سازمان چه زمانی در قبال یک حادثهٔ سایبری مسئول است. برای یک CISO، درک این مفاهیم حقوقی برای طراحی چارچوب‌های حاکمیتی، سیاست‌گذاری، و مدیریت ریسک حیاتی است.
آزمون نزدیکی نخستین گام در تعیین وجود یا عدم وجود تکلیف قانونی است. نزدیکی به این معناست که رابطهٔ سازمان با شخص زیان‌دیده آن‌قدر مستقیم، قابل‌پیش‌بینی و وابسته باشد که مسئولیت ایجاد کند. در فضای سایبری، این نزدیکی معمولاً قوی است: کاربران داده‌های حساس، تراکنش‌های مالی، احراز هویت و فعالیت‌های عملیاتی خود را به پلتفرم‌ها می‌سپارند. هرگاه چنین اتکایی وجود داشته باشد، دادگاه‌ها بیشتر به این نتیجه می‌رسند که سازمان مکلف است برای جلوگیری از خسارت‌های ناشی از فعالیت مجرمان سایبری اقدامات معقول انجام دهد.
پس از احراز نزدیکی، دادگاه‌ها وارد مرحلهٔ ملاحظات سیاستی (Policy Considerations) می‌شوند: عواملی مانند بار اقتصادی، خطر ایجاد مسئولیت نامحدود، یا تداخل با مقررات موجود. با این حال، هرچه وابستگی دیجیتال بیشتر می‌شود، این موانع سیاستی برای نفی تکلیف قانونی ضعیف‌تر شده‌اند-به‌ویژه زمانی که اهمال سازمانی می‌تواند زیان اقتصادی گسترده ایجاد کند.

نکتهٔ مهم دیگر آن است که پیش‌بینی‌پذیری معقولِ خطر (Reasonable Foreseeability) که زمانی آزمون مستقل بود، اکنون به یک پرسش واقعی در دلِ مفهوم نزدیکی تبدیل شده است. در عمل یعنی اگر تهدید سایبری شناخته‌شده، مستند در استانداردهای صنعتی، یا تجربه‌شده در گذشته باشد، سازمان دیگر نمی‌تواند ادعا کند از آن بی‌اطلاع بوده است. این موضوع برای CISOها یادآور ضرورت پایبندی به چارچوب‌های مطرح مانند NIST CSF و ISO 27001، پایش پیوسته تهدیدات، آمادگی حادثه و مدیریت ریسک تأمین‌کنندگان است.
در نهایت، همگرایی «نزدیکی»، «پیش‌بینی‌پذیری» و «انتظارات جدید حقوقی» به این معناست که امنیت سایبری برای CISO صرفاً یک مسئلهٔ فنی نیست؛ بلکه یک تکلیف قانونی مبتنی بر اعتماد، اتکا و اقدامات معقول حفاظتی است. کوتاهی در پیشگیری از خطرات قابل‌پیش‌بینی نه‌تنها تبعات فنی، بلکه مسئولیت مالی و حقوقی گسترده برای سازمان ایجاد می‌کند. بنابراین، ایجاد برنامه‌های امنیتی مستند، دفاع‌پذیر و همسو با ریسک، دیگر یک انتخاب نیست،بلکه بخشی ضروری از حاکمیت سازمانی مدرن به شمار می‌رود.


بخشی از دوره مدیریت امنیت CISO
البته تدریس با نگاه به قوانین ایران صورت خواهد گرفت

اینو دوست داشتم امشب


قبلاً برای اجرای دستور روی ماشین قربانی، کلی‌ها از DCOM Object‌ها مثل ShellWindows, ShellBrowserWindow, MMC20.Application استفاده می‌کردند.
ویندوزهای جدیدتر (۱۰، ۱۱، 2022، 2025) این‌ سناریوها رو تا حد زیادی خراب کردن (دست‌کم بدون دستکاری و فیکس).
نویسنده بررسی می‌کنه:
کدوم object هنوز کار می‌کند
روی چه نسخه‌هایی از ویندوز
مشکل دقیقاً کجاست
چطور می‌شه اسکریپت رو اصلاح کرد که دوباره قابل استفاده بشه
و میخواد تو قسمت‌های بعدی یک DCOM Object جدید معرفی کنه که هنوز برای command execution جواب می‌دهد .




https://sud0ru.ghost.io/yet-another-dcom-object-for-command-execution-part-1/

اهمیت ارتقای سیستم‌عامل در معماری امنیت سازمان
نمونهٔ تحلیلی: شکست تکنیک‌های DCOM در Windows 10/11


برای یک CISO، چرخهٔ عمر سیستم‌عامل و سیاست ارتقای آن دیگر یک «مسئلهٔ IT» نیست؛ بلکه بخشی از معماری امنیت سازمان و یکی از ستون‌های مدیریت ریسک مدرن است. تهدیدهای امروزی نه از یک نقص واحد، بلکه از شکاف‌های انباشته‌شده در سیستم‌عامل‌های قدیمی شکل می‌گیرند؛ نقاط ضعفی که معمولاً توسط مهاجمان برای Lateral Movement، Privilege Escalation و Persistence مورد سوءاستفاده قرار می‌گیرد.

یکی از نمونه‌های مهم این مسئله، رفتار متفاوت ویندوزهای قبل و بعد از Windows 10 در برابر تکنیک‌های سوءاستفاده از DCOM است.
سال‌ها، مهاجمان از COM Objectهایی مثل ShellWindows برای اجرای فرمان از راه دور (Remote Command Execution) در سناریوهای lateral movement استفاده می‌کردند. این تکنیک روی Windows 7، 8 و 8.1 به‌خاطر آزاد بودن مجوزهای Explorer و نبود سازوکارهای مدرن امنیتی کاملاً قابل اجرا بود. اما در Windows 10 و 11، چند تغییر بنیادی باعث شد این مسیر تقریباً از بین برود:

- محدودسازی شدید Activation Permissions برای DCOM
- جلوگیری از نوشتن خروجی توسط Explorer روی مسیرهای سیستمی مثل ADMIN$
- سخت‌گیری ویندوز روی اجرای فرایندها از بستر Explorer (حذف مسیرهای abuse)
- بلوغ معماری امنیتی ویندوز در لایه‌های User/Kernel، Credential Protection و Application Control

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

بنابراین یک CISO باید ارتقای سیستم‌عامل را در سه محور ببیند:
1. حذف مسیرهای شناخته‌شدهٔ سوءاستفاده (Exploit Surface Reduction)
2. بهره‌بردن از قابلیت‌های امنیتی Built‑in جدید مانند HVCI، LSA Protection، Memory Integrity
3. کاهش ریسک سیستم‌عامل‌های ناسازگار با ابزارهای دفاعی مدرن (EDR/XDR)

نمونهٔ DCOM و ShellWindows تنها یکی از ده‌ها موردی است که ثابت می‌کند امنیت واقعی از دل معماری به‌روز‌شدهٔ سیستم‌عامل نیز میتواند آغاز شود،

تبصره: دنیای هک نشان داده چیزی وجود ندارد که امکان باز انجام نداشته باشد پس شاید همین تکنیک روی ویندوز ۱۱ در آینده به نحو دیگری ممکن شود . پس یک CISO برای آنهم باید آماده باشد.


در نهایت اینکه یک CISO می‌داند همیشه اینکه بتواند ویندوز را ارتقاء دهد ندارد . راهکار چیست ؟


بخشی از مباحث درس مدیر امنیت CISO
منطبق بر چهار استاندارد آموزشی روز جهان

مهارت نرم CISO



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



نخست، اعتماد بین‌فردی بسیار اثرگذارتر از کنترل‌های رسمی عمل می‌کند. مدیران پروژه، تیم‌های DevOps و واحد عملیات زمانی همکاری مؤثر نشان می‌دهند که به بلوغ حرفه‌ای، شفافیت و قضاوت CISO باور داشته باشند. تجربه ثابت کرده امنیت با دستور پیش نمی‌رود، بلکه با اعتبار شخصی و سازمانی حرکت می‌کند.



دوم، یک CISO کارآمد باید همان اندازه که زبان فنی را می‌فهمد، زبان کسب‌وکار را نیز بداند. او باید بتواند با CFO درباره ROI و Cost Avoidance صحبت کند و با CTO درباره شاخص‌هایی مثل MTTD، Patch Lag و ظرفیت تیم‌ها. این ترجمه‌ی مداوم بین زبان‌ها، زمینه‌ی پذیرش و همکاری را فراهم می‌سازد.



سوم، شبکه‌سازی داخلی، مزیت پنهان اما حیاتی یک CISO است. بدون متحدانی در IT، حقوقی، مالی، منابع انسانی و عملیات، هیچ Policy یا Standard به مرحله‌ی اجرا نمی‌رسد. در کنار آن، توان مدیریت تعارض ضروری است؛ امنیت اغلب با اهداف کوتاه‌مدت واحدها اصطکاک پیدا می‌کند و تنها مذاکره‌ی هوشمندانه است که این فاصله را کم می‌کند.



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





بخشی از دوره مدیریت امنیت CISO

راه ارتباطی برای حضور از طریق واتس اپ 09902857290 www.haumoun.com

از جمله مطالعات اضافه در درس  مدیریت امنیت CISO

**فصل مدیریت پیشرفته امنیت هوش مصنوعی

ثبت نام از طریق واتس آپ 09902857290

وزارت دفاع ایالات متحده (DoD) با راه‌اندازی genai.mil به این جمع‌بندی رسیده است که هوش مصنوعی مولد را نمی‌توان از محیط‌های دولتی حذف کرد، بلکه باید آن را مدیریت و حاکمیت‌پذیر کرد. تجربه DoD نشان داد که ممنوع‌کردن ابزارهای GenAI تنها باعث گسترش استفاده پنهان (Shadow AI) و افزایش ریسک نشت داده می‌شود. بنابراین آمریکا به‌جای انکار واقعیت، یک پلتفرم رسمی، امن و تحت کنترل حاکمیتی ایجاد کرد تا هم بهره‌وری افزایش یابد و هم مسئولیت ریسک به‌صورت شفاف پذیرفته شود.

این genai.mil با اجرای GenAI روی زیرساخت‌های دولتی، کنترل لاگ‌ها، محدودسازی نوع داده‌های مجاز و خروج داده از چرخه آموزش عمومی مدل‌ها، امکان استفاده امن از این فناوری را فراهم کرده است. نتیجه این رویکرد، افزایش سرعت تحلیل، بهبود تصمیم‌سازی و کاهش وابستگی ناخواسته به سرویس‌های خارجی بوده است.

دولت ایران نیز دقیقاً با همین چالش روبه‌روست، اما با شدت بیشتر. از یک سو تحریم، حساسیت اطلاعات و وابستگی به سرویس‌های خارجی یک ریسک حاکمیتی جدی است؛ از سوی دیگر، کارمندان و مدیران دولتی عملاً از GenAI استفاده می‌کنند، اما بدون چارچوب، لاگ و مسئول رسمی پذیرش ریسک. ایجاد یک پلتفرم GenAI دولتی و کنترل‌شده در ایران نه به‌معنای لوکس‌سازی فناوری، بلکه اقدامی برای جلوگیری از نشت داده، کاهش Shadow AI و وادارکردن مدیریت ارشد به پذیرش رسمی ریسک است. مسیر genai.mil نشان می‌دهد که حاکمیت هوشمند، فقط با پذیرش واقعیت و مدیریت آن ممکن می‌شود، نه با ممنوعیت.


نکته ۱: پلتفرم فوق برای داده های طبقه بندی شده نیست و برای استفاده های جاسوسی،و نظامی احتمالا مدلهای خاصی از قبل وجود داشته است. پیشنهاد فوق فقط برای استفاده در حوزه داده های غیر دسته بندی شده یا غیر محرمانه است

نکته ۲: راه اندازی چنین پلتفرمی جدای از نیاز به زیرساخت پردازشی بالا ، نیازمند طراحی و پیاده سازی امنیت در لایه های مختلف با ظرافت و دقت بالا به همراه مدیریت پروژه قوی است . این امر با صدور بخشنامه ولی عدم پیگیری دقیق ممکن نیست و لذا درصورت عدم تحقق مواردی که دربالا گفتم شاید همان بهتر که چنین سیستمی راه نیفتد!!

یکی از دانشجو هام در مورد این پرسید:
چرا هکر ها JA3 رو کامل مانند اثر انگشت مرورگر درست نمیکنند تا شناخته نشوند؟

این سوال مقدمه ای بر این شد که بحث کشف ترافیک مشکوک رمز شده با JA3 رو باز کنم و در مورد JA4 هم بنویسم

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

در ویرگول بخوانید

https://vrgl.ir/MN090

نمونه‌هایی از Security Decision Points در SDLC:

مرحله Requirements Gate: تأیید الزامات امنیتی قبل از طراحی
مرحله Architecture Gate: تأیید امنیت طراحی قبل از توسعه
مرحله Code Review Gate: تأیید امنیت کد قبل از پیاده‌سازی
مرحله Pre-Deployment Gate: تأیید امنیت قبل از رفتن به محیط عملیاتی

این گیت‌ها مانند چک‌پوینت‌های کنترل کیفیت هستند اما با محوریت امنیت.


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

مقوله KPI چیست؟
بحث KPI یا Key Performance Indicator شاخصی است که عملکرد یک فعالیت امنیتی را اندازه‌گیری می‌کند.
آنچه KPI می‌گوید:
«آیا کاری که باید انجام دهیم، واقعاً انجام شده و چقدر مؤثر است؟»
به بیان دیگر، KPI روی Performance متمرکز است و موفقیت فرآیند، ابزار یا تیم را نشان می‌دهد.

مثال‌های KPI امنیتی
مقوله MTTD (Mean Time to Detect): متوسط زمان شناسایی رخداد توسط SOC.
مقولهMTTR (Mean Time to Respond): سرعت پاسخ‌دهی تیم امنیت.
بحث Patch Compliance Rate: درصد سیستم‌هایی که در زمان مقرر پَچ شده‌اند.
بحث Phishing Reporting Rate: درصد کارمندانی که ایمیل مشکوک را گزارش می‌کنند (همان موضوعی که قبلاً درباره‌اش مقاله ای در همین جا درج کردیم).
و Backup Restore Success Rate: موفقیت بازیابی پشتیبان‌ها در تست‌های دوره‌ای.
این‌ها عملکرد فرآیندها را نشان می‌دهند.


و اما KRI چیست؟
مقولهKRI یا Key Risk Indicator شاخصی است که ریسک را اندازه‌گیری یا پیش‌بینی می‌کند.
و KRI می‌گوید:
«احتمال وقوع یک ریسک مهم چقدر است و آیا دارد بدتر می‌شود؟»
این KRI روی Risk Exposure تمرکز دارد، نه عملکرد تیم یا ابزار.

مثال‌های KRI امنیتی
تعداد آسیب‌پذیری‌های بحرانی باز مانده بیش از X روز (نشانه افزایش ریسک Exploitation).
افزایش موفقیت تست‌های Social Engineering (نشانه ریسک بالاتر از رفتار انسانی).
افزایش فعالیت‌های مشکوک در احراز هویت مانند Failed Loginهای تکراری.
افزایش نرخ داده‌های حساس شناسایی‌شده خارج از محدودهٔ سیاست DLP.
تعداد سیستم‌های EOL یا Unsupported در محیط عملیاتی.
این‌ها سطح ریسک کلی سازمان را نشان می‌دهند.


تفاوت KPI و KRI در یک نگاه ساده
در KPI: آیا کار درست انجام شد؟ (عملکرد / کیفیت / سرعت عملیات)
در KRI: آیا احتمال بروز حادثه یا ریسک مهم در حال افزایش است؟ (نمای ریسک)

یک مثال ساده:
در KPI: درصد موفقیت Patch Management = ۹۵٪
درKRI: تعداد Vulnerabilityهای Critical پَچ نشده = ۲۵ مورد : ریسک بالا
ممکن است KPI عالی باشد ولی KRI هشدار دهد که سازمان هنوز در معرض خطر است.


در دوره مدیر امنیت CISO با استاد روزبه نوروزی دارای مدرک عالی CISSP بیشتر بیاموزیم.

چرا انتخاب واژگان در سیاست‌نامه‌ها -policy- یک ریسک حقوقی و مدیریتی است؟


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

مثال کلاسیک در تمام دوره‌های Governance و Legal Risk همین تفاوت ساده است:

“the enterprise will terminate employees who do this”
“the enterprise may terminate employees who do this”

در نگاه اول تفاوت ناچیزی دارند، اما اثر مدیریتی و حقوقی آن‌ها عمیق است.

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

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

البته نوشتن پالیسی جزییات دیگری هم دارد
در دوره مدیریت امنیت CISO با تبعات قضایی تصمیمات خود آشنا شوید.

واتس اپ 09902857290
www.haumoun.com

برون سپاری های پر ریسک

در اطلاعیه های مناقصات شاهدم که برون سپاری های IT و امنیت درحال رشد است.
نفس این عمل مورد بحث نیست چه اینکه بسیاری از کشور ها هم بدین سمت رفته اند اما با رعایت قوانین چون SOC2

امروز بحثم قوانین برون سپاری نیست چرا که در پستهای قبلی بدین موضوع پرداخته ام.
بحث الان در خصوص کیفیت برون سپاری است.

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

این می‌شود که بسیاری از برون سپاری های امروز کشور؛ خودش یک ریسک برای سازمان و پیمانکار است.

درسی از شرایط امروز بانک‌ها برای CISO

تحلیل اختلال سامانه ثبت احوال از منظر CISO

اختلال مداوم سامانه ثبت احوال در این روزها ( انتهای آذرماه ۱۴۰۴) که منجر به محدود شدن فرآیند افتتاح حساب بانکی به چند ساعت در روز شده، نمونه‌ای روشن از شکست در مدیریت امنیت و ریسک در سطح بین‌سازمانی است. از منظر CISSP، مسئله اصلی نه یک نقص صرفاً فنی، بلکه ضعف در حاکمیت خدمات دیجیتال حیاتی و مدیریت وابستگی‌های بحرانی است.
سامانه ثبت احوال به‌عنوان مرجع ملی هویت، نقش یک دارایی حیاتی مشترک را ایفا می‌کند که در زنجیره اعتماد بانک‌ها و فرآیندهای KYC جایگاه محوری دارد. با این حال، این نقش حیاتی در طراحی، ظرفیت‌سنجی و برنامه‌های تداوم کسب‌وکار به‌درستی لحاظ نشده است.

این اختلال اثرات مستقیم و غیرمستقیم متعددی دارد؛ از جمع‌شدن صف‌های عملیاتی و نارضایتی مشتریان گرفته تا کاهش درآمد و افزایش فشار بر کارکنان شعب. در سطح عمیق‌تر، محدودیت دسترسی به سامانه، بانک‌ها را در معرض ریسک‌های پنهان انطباق، تقلب و دور زدن کنترل‌های هویتی قرار می‌دهد. تمرکز ریسک بر یک سامانه بدون مکانیسم‌های جایگزین، باعث ایجاد «Single Point of Trust and Failure» شده که با اصول تاب‌آوری سازمانی در تضاد است.

آنچه در این میان مغفول مانده، نبود تحلیل اثر بر کسب‌وکار مشترک، حمایت از یکدیگر ، فقدان SLA و RTO الزام‌آور، و عدم تعریف سازوکارهای اعتماد جایگزین مانند افتتاح حساب مشروط یا سطوح متفاوت اطمینان هویتی است. استانداردهایی نظیر ISO/IEC 27001، ISO 22301، COBIT 2019 و چارچوب‌های حاکمیت IT تأکید می‌کنند که مدیریت ریسک باید در سطح اکوسیستم و با مالکیت شفاف اثرات کسب‌وکار انجام شود. تا زمانی که این نگاه حاکمیتی اصلاح نشود، اختلال‌ها صرفاً درمان علامتی خواهند شد، نه حل ریشه‌ای مسئله.


برای شرکت در دوره مدیریت امنیت CISO به واتس اپ 09902857290 یا واحد آموزش شرکت هامون پیام دهید www.haumoun.com

#امنیت_به_زبان_ساده

آشنایی با اتربیوشن

مقوله Attribution در Incident Responseیعنی پاسخ به این سؤال مدیریتی و راهبردی که «این حمله را چه کسی، با چه سطح اطمینان، و برای چه هدفی انجام داده است؟»

بحثAttribution صرفاً یک تحلیل فنی نیست؛ بلکه ترکیبی از شواهد فنی، زمینه عملیاتی، انگیزه، و قضاوت ریسک است. این عمل به‌ندرت ۱۰۰٪ قطعی است و تقریباً همیشه احتمالی است .



در لایه فنی، نشانه‌هایی مثل:
- بحث TTPها (روش‌ها و الگوهای حمله)
- ابزارها و malware family
- زیرساخت C2
- زمان‌بندی حمله و زبان/کامنت‌های کد
به ما می‌گویند حمله «شبیه چه گروهی» است، نه الزاماً دقیقاً همان گروه.

اما attribution واقعی بدون Context ممکن نیست:
- آیا انگیزه مالی است یا جاسوسی؟
- آیا سازمان ارزش استراتژیک دارد؟
- آیا الگوی حمله با کشور/صنعت خاصی همخوانی دارد؟



هدف attribution تصمیم‌سازی است، نه اثبات قضایی

#امنیت_به_زبان_ساده

تزریق در پراسس برای نفوذ


تزریق در فرآیند یا Process Injection یعنی مهاجم کد مخرب خود را داخل یک برنامهٔ سالم و در حال اجرا تزریق می‌کند تا به‌جای اجرای یک برنامهٔ جدید، پشت هویت یک برنامهٔ معتبر پنهان شود.
مثلاً به‌جای اجرای malware.exe، کد خود را داخل explorer.exe یا chrome.exe اجرا می‌کند.

ایدهٔ اصلی خیلی ساده است:

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

این تکنیک معمولاً برای ورود اولیه نیست؛ بلکه بعد از نفوذ استفاده می‌شود تا مهاجم:
- شناسایی نشود (Defense Evasion)
- دسترسی خود را حفظ کند
- یا سطح دسترسی را بالا ببرد

از نگاه مدیریتی، ریسک اصلی این است که دید امنیتی صرفاً مبتنی بر Asset و Process Name باشد، نه رفتار. این باعث می‌شود مهاجم مدت زیادی در سیستم باقی بماند بدون اینکه آلارم واضحی ایجاد شود.

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


شماره این تکنیک در جدول مایتره
T1055 – Process Injection


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