آکادمی آموزش روزبه 📚 – Telegram
آکادمی آموزش روزبه 📚
3.75K subscribers
4.56K photos
184 videos
1.46K files
6.92K links
🍎آموزش و ترویج علمی فناوری اطلاعات ، امنیت و مدیریت پروژه های مرتبط
🍁 و کمی هم اخلاق و انسانیت

Training of Information Technology, Cyber Security, Project Management, Ethics and Humanitarian

ارتباط با مدیر کانال:
@roozbehadm
Download Telegram
آنچه که در ایران امروز برای برون سپاری بدان نیازمندیم:

نقش SOC 2 Type II در کنترل‌های زنجیره تأمین (Supply Chain Security Controls)

در مدیریت امنیت زنجیره تأمین، یکی از چالش‌های اصلی این است که سازمان بتواند اعتماد قابل اتکا نسبت به امنیت عرضه‌کنندگان (vendors)، ارائه‌دهندگان سرویس، و پیمانکاران ایجاد کند. بسیاری از تهدیدهای امروزی نه از طریق نقطه‌ضعف داخلی، بلکه از طریق زیر‌تأمین‌کنندگان (Sub-tier Suppliers) وارد محیط سازمان می‌شوند. به همین دلیل، چارچوب‌های مدیریت ریسک پیشرفته مانند NIST SP 800-161 و برنامه‌های آموزش ISSMP تأکید می‌کنند که سازمان‌ها باید مکانیسم‌هایی برای تأیید امنیت عملیاتی تأمین‌کنندگان داشته باشند. یکی از معتبرترین روش‌ها برای این ارزیابی، دریافت و بررسی گزارش SOC 2 Type II است.
گزارش SOC 2 Type II، برخلاف Type I، تنها طراحی کنترل‌ها را ارزیابی نمی‌کند، بلکه اثربخشی واقعی کنترل‌ها را در یک دوره زمانی چندماهه بررسی می‌کند. این ویژگی، SOC 2 Type II را به یک ابزار قدرتمند در ارزیابی امنیت زنجیره تأمین تبدیل می‌کند؛ زیرا به سازمان نشان می‌دهد که آیا عرضه‌کننده در عمل به کنترل‌های امنیتی پایبند بوده است یا خیر، نه فقط روی کاغذ.
در حوزه زنجیره تأمین، این گزارش نقش‌های کلیدی زیر را ایفا می‌کند:
✅️تأیید یکپارچگی عملیاتی Vendor از طریق شواهد مستند عملکرد کنترل‌ها (Access Control, Logging, Incident Response).
✅️کاهش ریسک ناشی از Third-Party Software و Cloud Providers با بررسی مستمر رویه‌های امنیتی آن‌ها.
✅️کاهش احتمال نفوذهای زنجیره تأمینی؛ مشابه حملاتی مانند SolarWinds که در اثر ضعف Vendor رخ داد.
✅️تضمین انطباق (Compliance Assurance) در برابر نیازهای قانونی، قراردادی و سیاست‌های داخلی سازمان.
✅️ایجاد قابلیت اعتماد (Assurance) برای اعطای ATO؛ به‌ویژه در محیط‌هایی که سیستم‌ها بر مبنای اعتماد به تأمین‌کنندگان بنا شده‌اند.

در نهایت، SOC 2 Type II به‌عنوان یک ابزار ساختاریافته و مبتنی بر شواهد، به مدیر امنیت کمک می‌کند تا ریسک‌های زنجیره تأمین را قابل اندازه‌گیری، قابل مانیتور و قابل کنترل سازد. استفاده از این گزارش، بخشی حیاتی از فرآیند Third-Party Risk Management (TPRM) و الزامی برای دریافت اعتماد امنیتی در معماری‌های مدرن و اکوسیستم‌های امروزی است.


📊برگرفته از دوره مدیر امنیت CISO
09902857290 www.haumoun.com
Please open Telegram to view this post
VIEW IN TELEGRAM
4💯2
چرا امنیت سایبری ایران شکننده است؟ حلقه مفقوده «پذیرش ریسک»

یکی از بزرگ‌ترین چالش‌های امنیت سایبری در ایران، ضعف تکنولوژیک یا کمبود دانش فنی نیست؛ بلکه ریشه در یک نقیصه ساختاری و مدیریتی عمیق دارد: «عدم پذیرش رسمی ریسک توسط مدیران ارشد». در حالی که استانداردهای جهانی مانند NIST و سرفصل CISSPبر این اصل استوارند که امنیت صددرصدی وجود ندارد و ریسک‌های باقی‌مانده (Residual Risk) باید توسط بالاترین مقام اجرایی سازمان پذیرفته شوند، در ایران این چرخه معیوب است.

فقدان مالکیت ریسک در سطح مدیریت
در چارچوب‌های استاندارد جهانی، مدیر ارشد سازمان (Authorizing Official) تنها کسی است که حق دارد مسئولیت ریسک باقی‌مانده را بپذیرد و مجوز بهره‌برداری (ATO) صادر کند. در ایران اما، این فرآیند اغلب وارونه است. مدیران ارشد به جای آنکه «مالک ریسک» باشند، مسئولیت امنیت را تماماً به تیم‌های فنی و IT واگذار می‌کنند. این تصور غلط که «اگر نفوذی رخ داد، تقصیر واحد IT است»، باعث می‌شود ریسک‌های حیاتی پنهان بمانند و سرمایه‌گذاری لازم برای امنیت انجام نشود.

فرهنگ واکنشی به جای رویکرد مبتنی بر ریسک
مشکل دیگر، تبدیل شدن امنیت از یک فرآیند «ریسک‌محور» (Risk-Based) به یک واکنش «رخدادمحور» (Event-Based) است. در مدل صحیح، ابتدا تحلیل ریسک انجام می‌شود، بودجه تخصیص می‌یابد و پس از پذیرش ریسک توسط مدیر، سیستم عملیاتی می‌شود. اما در بسیاری از سازمان‌های ایرانی، سیستم‌ها صرفاً به دلیل «نیاز عملیاتی» و بدون دریافت مجوز امنیتی واقعی (ATO) راه‌اندازی می‌شوند. استراتژی غالب این است: «سیستم را بالا ببرید، اگر مشکلی پیش آمد، آن را وصله‌پینه می‌کنیم.»

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

❤️دوره مدیر امنیت CISO
www.haumoun.com
09902857290
Please open Telegram to view this post
VIEW IN TELEGRAM
4👏3
#نکته_ریزه_در_امنیت
تقویت امنیت احراز هویت MAB در شبکه‌های سازمانی مبتنی بر Cisco ISE


در معماری‌های شبکه سازمانی که از Cisco ISE (Identity Services Engine) برای کنترل دسترسی استفاده می‌کنند، روش MAB – MAC Authentication Bypass اغلب برای تجهیزاتی به کار می‌رود که از احراز هویت 802.1X پشتیبانی نمی‌کنند؛ مانند چاپگرها، تلفن‌های IP یا تجهیزات IoT. این مکانیزم به سوئیچ اجازه می‌دهد با استفاده از آدرس MAC دستگاه، احراز هویت اولیه را انجام دهد. هرچند MAB ساده و سازگار با تجهیزات قدیمی است، اما ذاتاً ضعف امنیتی مهمی دارد: آدرس MAC را می‌توان به‌آسانی جعل (Spoof) کرد و مهاجم می‌تواند با تقلید MAC دستگاه مجاز، دسترسی غیرمجاز به شبکه به‌دست آورد. این مسئله به‌ویژه در لایه دسترسی (Access Layer) خطرناک است، زیرا مهاجم مستقیماً به شبکه داخلی متصل می‌شود و ممکن است به منابع حساس دسترسی پیدا کند.

برای کنترل این ریسک، باید MAB در کنار چندین لایه‌ حفاظتی استفاده شود. نخستین اقدام، فعال‌سازی Device Profiling در ISE است تا نوع واقعی دستگاه بر اساس ویژگی‌های شبکه‌ای (DHCP، SNMP، LLDP Fingerprint) شناسایی شود و از ورود دستگاه‌های جعل‌شده جلوگیری گردد. سپس، تخصیص VLAN محدود (Restricted VLAN) برای همه دستگاه‌های MAB باعث می‌شود حتی در صورت حمله، دسترسی مهاجم به حداقل برسد. در سطح سوئیچ نیز باید از Port Security با تنظیم پارامترهایی مانند Sticky MAC و Maximum 1 MAC per Port استفاده کرد تا ورود MAC جدید غیرمجاز موجب غیرفعال شدن پورت شود.

افزون‌بر این، اجرای زمان‌بندی Re-authentication، محدود کردن مدت اعتبار نشست‌ها، و به‌کارگیری Cisco TrustSec SGT Tagging برای تفکیک منطقی جریان‌های ترافیکی موجب کاهش سطح حمله و افزایش قابلیت کنترل می‌شود. ترکیب این ابزارها موجب می‌شود MAB- با وجود سادگی و ضعف ذاتی در برابر Spoofing-به روشی امن‌تر و قابل اعتماد برای شبکه‌های بزرگ تبدیل گردد.




متخصص کسی است که چالش را حل میکند. متخصص امنیت کسی است که برای دنیای پرچالش امنیت راهکارهای مقرون به صرفه در راستای بیزنس و قانون دارد ( بخشی از درس CISSP)
4💯3
محیط های کوبرنتیز و کانتینر در خیلی از سازمانها رها شده اند در سلسله مقالاتی خطراتی که متوجه این سازمانها هستند را بررسی میکنم

خطرات نبود 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) استفاده می‌شود
3👏2
فناوری‌های نوین در خدمت BCP

فناوری Kubernetes به عنوان یک پلتفرم ارکستریشن کانتینر، نقش مهمی در تحقق الزامات Business Continuity Planning (BCP) ایفا می‌کند و از دید یک CISSP، ارزش آن فراتر از یک ابزار فنی است.
نخستین مزیت Kubernetes، توانایی Self‑Healing و مدیریت هوشمند خرابی است. در معماری‌های سنتی، توقف یک سرویس نیازمند مداخله انسانی است و این وضعیت RTO را افزایش می‌دهد. اما در Kubernetes، سرویس‌ها دائماً پایش می‌شوند و در صورت توقف، کانتینر یا Pod جدید به‌طور خودکار جایگزین می‌شود. این رفتار، RTO را به نزدیک صفر می‌رساند و از منظر BCP یک مزیت ساختاری محسوب می‌شود.

مزیت دوم، توانایی Auto‑Scaling است که از توقف سرویس در زمان حملات ترافیکی، رخدادهای پیش‌بینی‌نشده یا تغییرات ناگهانی بار جلوگیری می‌کند. با افزایش بار، Kubernetes ظرفیت پردازشی را افزایش می‌دهد و در زمان کاهش بار، هزینه‌ها را پایین می‌آورد. این تطبیق‌پذیری مستقیم به هدف BCP یعنی حفظ Availability در شرایط فشار کمک می‌کند.

مزیت سوم، معماری دکلراتیو و مبتنی‌بر GitOps است. در بحران‌هایی که زیرساخت فیزیکی یا منطقی آسیب می‌بیند، Kubernetes اجازه می‌دهد کل سیستم در چند دقیقه در یک Cluster جدید بازسازی شود، زیرا وضعیت کل محیط در قالب فایل‌های YAML و ذخیره‌شده در Git نگهداری می‌شود. این ویژگی RPO را به شکل چشمگیری کاهش می‌دهد.

مزیت چهارم، امکان استقرار Multi‑Cluster و Multi‑Region است. سازمان‌ها می‌توانند یک Cluster در دیتاسنتر و یک نمونه در Cloud داشته باشند و با استفاده از Service Mesh یا Load Balancing هوشمند، Tolerance جغرافیایی ایجاد کنند. این موضوع یکی از نیازمندی‌های کلیدی BCP در NIST 800‑34 است.

در مجموع، Kubernetes با ارائه Self‑Healing، Auto‑Scaling، بازسازی سریع، معماری دکلراتیو و تاب‌آوری جغرافیایی، یک توانمندساز جدی برای BCP است؛ البته به شرط طراحی درست، Observability کامل و بلوغ تیم DevSecOps.


و اما معایب کوبر چیست ؟



www.haumoun.com
📡دوره های CISSP و دوره CISO
09902857290
Please open Telegram to view this post
VIEW IN TELEGRAM
4👏2
مثالی از سه شاخصه در SOC

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

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

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

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

#اشتراک_دانش و #تجربه
10
CISO سرفصل دوره مدیریت ارشد امنیت .pdf
219.4 KB
سرفصل دوره مدیریت ارشد امنیت CISO
09902857290
8
یکی گفته بود این نوروزی اینقدر پست میگذاره ، کار هم میکنه ؟!!

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

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



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



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

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

با احترام . تمام💫
20👏4🤓2
بهینه‌سازی رول‌های سیگما با استفاده از 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 بهترین کیفیت نتیجه را می‌دهد.
5
مسئولیت حقوقی امنیت سایبری، آزمون نزدیکی، و تکلیف قانونی:
تحلیل راهبردی برای مدیران ارشد امنیت اطلاعات (CISO)

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

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


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


قبلاً برای اجرای دستور روی ماشین قربانی، کلی‌ها از 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/
5
اهمیت ارتقای سیستم‌عامل در معماری امنیت سازمان
نمونهٔ تحلیلی: شکست تکنیک‌های 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
منطبق بر چهار استاندارد آموزشی روز جهان
3💯3
📡محیط های داکر و کوبر رو حواستون باشه

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

حتما EDR توی کوبر نصب کنید📡
Please open Telegram to view this post
VIEW IN TELEGRAM
👌71
مهارت نرم CISO



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



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



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



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



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





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

راه ارتباطی برای حضور از طریق واتس اپ 09902857290 www.haumoun.com
5👍4
aaism.pdf
8.3 MB
از جمله مطالعات اضافه در درس  مدیریت امنیت CISO

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

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

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

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


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

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

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

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

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

https://vrgl.ir/MN090
👏6
نمونه‌هایی از Security Decision Points در SDLC:

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

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


#آکادمی_روزبه
4
مقوله 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 بیشتر بیاموزیم.
3💯3
چرا انتخاب واژگان در سیاست‌نامه‌ها -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
5
برون سپاری های پر ریسک

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

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

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

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