راهنمای لاگ گیری در لینوکس
از CrowdStrike
#آکادمی_روزبه
مرکز تخصصی CISSP
https://www.crowdstrike.com/en-us/guides/linux-logging/
از CrowdStrike
#آکادمی_روزبه
مرکز تخصصی CISSP
https://www.crowdstrike.com/en-us/guides/linux-logging/
CrowdStrike.com
<strong>Linux Logging Guide</strong>:
The Basics
The Basics
In part one of a series on Linux logging, we will go over the common Linux logging framework, locations of these log files, and the different types of logging daemons and protocols
⚡5
امکان سوءاستفاده سختافزاری از طریق رابطهای پنهان دیباگ (مطالعه موردی: EUD/JTAG در چیپستهای Qualcomm)
✅️بخشی از دوره مدیریت بحران سایبری آکادمی روزبه
مقدمه
در عصر اینترنت اشیاء، موبایل و تجهیزات متصل، امنیت سختافزاری کمتر از لایه نرمافزاری مورد توجه قرار گرفته است. در حالی که تمرکز اکثر تیمهای امنیت بر آسیبپذیریهای نرمافزاری و شبکهای است، وجود رابطهای دیباگ پنهان نظیر JTAG و EUD (Embedded USB Debug) در بسیاری از سختافزارهای مدرن، به یک خطر بالقوه تبدیل شده است. این منافذ به مهاجم امکان میدهد فارغ از محدودیتهای سیستمعامل یا حتی Secure Boot، کنترل سطح پایین دستگاه را در اختیار بگیرد.
ماهیت تهدید
رابطهایی مانند JTAG و SWD (Serial Wire Debug)، طراحی شدهاند تا توسعهدهندگان و تعمیرکاران بتوانند سختافزار را دیباگ و تحلیل کنند. در بسیاری از پردازندههای موبایلی نظیر Qualcomm Snapdragon، این رابطها به شکل پنهان، در پورت USB ادغام یا از طریق فریمویر فعال میشوند (مانند EUD). به تازگی کد منبع تعامل با EUD به صورت عمومی منتشر شده و امکان بهرهبرداری از این دسترسی بدون نیاز به باز کردن دستگاه و ابزارآلات خاص فراهم گردیده است.
سناریوهای سوءاستفاده عملی
۱. کسب دسترسی کامل سختافزاری:
اگر EUD یا JTAG فعال باشد، مهاجم میتواند با اتصال به پورت USB، به رجیسترهای داخلی، حافظه و کنترل کامل پردازنده برسد. این دسترسی در خارج از کنترل سیستمعامل است و عملاً تمام لایههای امنیتی نرمافزاری را دور میزند.
تزریق بدافزار پایدار یا روتکیت:
مهاجم میتواند فریمویر را تغییر داده، implant دائمی نصب کند یا حتی کل image دستگاه را dump و بررسی کند.
تهدید Supply Chain:
اگر تجهیزات سازمانی یا تجهیزات IoT با Debug Interface فعال وارد چرخه مصرف شوند، همان ابتدای زنجیره تامین ریسک implant فیزیکی و زدودن شفافیت امنیتی را ایجاد میکند.
پیشنهاد به تیمهای امنیت
تجهیزات خود را ممیزی و وضعیت Debug Interfaceها را بررسی کنید.
در صورت عدم نیاز، اینترفیسهای دیباگ را غیرفعال و فیوزهای امنیتی را فعال کنید.
بهروزرسانی منظم فریمویر را جدی بگیرید و تامینکنندگان سختافزار را اعتبارسنجی نمایید.
امنیت سختافزاری را جزو چکلیستهای ارزیابی فنی و تست نفوذ قرار دهید.
نتیجهگیری
امنیت سختافزاری سنگبنای امنیت دیجیتال است و غفلت از پتانسیل سوءاستفاده از منافذ سختافزاری میتواند تمامی لایههای منطقی دفاع را بیاثر کند. توجه مداوم به این لایه، رکن حیاتی امنیت سازمانهای امروزی است.
#آکادمی_روزبه
مرکز تخصصی CISSP
✅️بخشی از دوره مدیریت بحران سایبری آکادمی روزبه
مقدمه
در عصر اینترنت اشیاء، موبایل و تجهیزات متصل، امنیت سختافزاری کمتر از لایه نرمافزاری مورد توجه قرار گرفته است. در حالی که تمرکز اکثر تیمهای امنیت بر آسیبپذیریهای نرمافزاری و شبکهای است، وجود رابطهای دیباگ پنهان نظیر JTAG و EUD (Embedded USB Debug) در بسیاری از سختافزارهای مدرن، به یک خطر بالقوه تبدیل شده است. این منافذ به مهاجم امکان میدهد فارغ از محدودیتهای سیستمعامل یا حتی Secure Boot، کنترل سطح پایین دستگاه را در اختیار بگیرد.
ماهیت تهدید
رابطهایی مانند JTAG و SWD (Serial Wire Debug)، طراحی شدهاند تا توسعهدهندگان و تعمیرکاران بتوانند سختافزار را دیباگ و تحلیل کنند. در بسیاری از پردازندههای موبایلی نظیر Qualcomm Snapdragon، این رابطها به شکل پنهان، در پورت USB ادغام یا از طریق فریمویر فعال میشوند (مانند EUD). به تازگی کد منبع تعامل با EUD به صورت عمومی منتشر شده و امکان بهرهبرداری از این دسترسی بدون نیاز به باز کردن دستگاه و ابزارآلات خاص فراهم گردیده است.
سناریوهای سوءاستفاده عملی
۱. کسب دسترسی کامل سختافزاری:
اگر EUD یا JTAG فعال باشد، مهاجم میتواند با اتصال به پورت USB، به رجیسترهای داخلی، حافظه و کنترل کامل پردازنده برسد. این دسترسی در خارج از کنترل سیستمعامل است و عملاً تمام لایههای امنیتی نرمافزاری را دور میزند.
تزریق بدافزار پایدار یا روتکیت:
مهاجم میتواند فریمویر را تغییر داده، implant دائمی نصب کند یا حتی کل image دستگاه را dump و بررسی کند.
تهدید Supply Chain:
اگر تجهیزات سازمانی یا تجهیزات IoT با Debug Interface فعال وارد چرخه مصرف شوند، همان ابتدای زنجیره تامین ریسک implant فیزیکی و زدودن شفافیت امنیتی را ایجاد میکند.
پیشنهاد به تیمهای امنیت
تجهیزات خود را ممیزی و وضعیت Debug Interfaceها را بررسی کنید.
در صورت عدم نیاز، اینترفیسهای دیباگ را غیرفعال و فیوزهای امنیتی را فعال کنید.
بهروزرسانی منظم فریمویر را جدی بگیرید و تامینکنندگان سختافزار را اعتبارسنجی نمایید.
امنیت سختافزاری را جزو چکلیستهای ارزیابی فنی و تست نفوذ قرار دهید.
نتیجهگیری
امنیت سختافزاری سنگبنای امنیت دیجیتال است و غفلت از پتانسیل سوءاستفاده از منافذ سختافزاری میتواند تمامی لایههای منطقی دفاع را بیاثر کند. توجه مداوم به این لایه، رکن حیاتی امنیت سازمانهای امروزی است.
#آکادمی_روزبه
مرکز تخصصی CISSP
❤4
وقتی فرآیند صدور مجوز امنیتی برای کسب و کار ها ضعیف اجرا بشه ؛ هرکسی میتونه اطلاعاتی داشته باشه که نباید.
اطلاعات این سایت شاید در برخی ترور ها مؤثر بوده .
فعلا که سایت رسمیو که اطلاعات شرکتها رو ریخته بود کف اینترنت از دسترس خارج شده که این خوبه
امید که من بعد مجوز به چنین کسب و کارهایی با دقت بیشتری انجام بشه
اطلاعات این سایت شاید در برخی ترور ها مؤثر بوده .
فعلا که سایت رسمیو که اطلاعات شرکتها رو ریخته بود کف اینترنت از دسترس خارج شده که این خوبه
امید که من بعد مجوز به چنین کسب و کارهایی با دقت بیشتری انجام بشه
👍6💯4
آکادمی آموزش روزبه 📚
وقتی فرآیند صدور مجوز امنیتی برای کسب و کار ها ضعیف اجرا بشه ؛ هرکسی میتونه اطلاعاتی داشته باشه که نباید. اطلاعات این سایت شاید در برخی ترور ها مؤثر بوده . فعلا که سایت رسمیو که اطلاعات شرکتها رو ریخته بود کف اینترنت از دسترس خارج شده که این خوبه امید که…
مساله دیگری که درخصوص اطلاعات درج شده در این سایت هست که آدم متاسف میشه ازش ، رانت هست. خیلی ها که در ایران در حوزه امنیت کار میکنند حتی نمیتونن لینکدین داشته باشند یا محل کارشون رو در لینکدین بنویسند حتی اگر یک بانک باشه.
اما از اون طرف دانشمندان هسته ای ما در شرکت های مختلف عضو بودن و اسمشون به راحتی هرجایی بوده. لذا خیلی هم تقصیر سایت رسمیو نیست . تقصیر خود اون دانشمند و حراست واحد های مربوطه هم هست.
درسته رسمیو طبقه بندی اطلاعاتی نداشته و از این بابت مقصره ولی خود اون افراد هم نباید اینقدر تابلو اطلاعاتشون رو اینور و اونور میدادند.
✅انشالله از دوشنبه مباحث OPSEC و SECOPS رو در دوره مدیریت بحران سایبری بررسی و تدریس خواهم کرد.
اما از اون طرف دانشمندان هسته ای ما در شرکت های مختلف عضو بودن و اسمشون به راحتی هرجایی بوده. لذا خیلی هم تقصیر سایت رسمیو نیست . تقصیر خود اون دانشمند و حراست واحد های مربوطه هم هست.
درسته رسمیو طبقه بندی اطلاعاتی نداشته و از این بابت مقصره ولی خود اون افراد هم نباید اینقدر تابلو اطلاعاتشون رو اینور و اونور میدادند.
✅انشالله از دوشنبه مباحث OPSEC و SECOPS رو در دوره مدیریت بحران سایبری بررسی و تدریس خواهم کرد.
👍4💯2
نگاهی به تاریخچه نشت ابزارهای تجاری هک
(از Red Team تا سلاح واقعی نزد مهاجمان)
مقدمه
در سالهای اخیر، موجی از نشت و افشای ابزارهای حرفهای و تجاری هک و Red Team به دست هکرها و مهاجمان واقعی افتاده است. ابزارهایی که اساساً با هدف تست نفوذ قانونی، ارزیابی امنیت سازمانها و آموزش نیروهای امنیتی توسعه یافتهاند، پس از نشت، به سلاحهای مورد علاقه مهاجمان برای طراحی حملات واقعی تبدیل شدهاند. این وقایع، چالشهای تازهای برای تیمهای SOC و عملیات دفاعی به همراه آورده است.
موارد مشهور نشت ابزارهای هک (Timeline)
1. Hacking Team Leak (2015)
توضیح: شرکت ایتالیایی Hacking Team تولیدکننده نرمافزار نظارتی RCS Galileo بود. در سال ۲۰۱۵، نزدیک به ۴۰۰ گیگابایت داده شامل سورسکد و exploit به صورت عمومی نشت یافت.
پیامد: آسیبپذیریهای zero-day، ابزارهای C2 و exploitها به صورت گسترده مورد سوءاستفاده مهاجمان از جمله APTها قرار گرفت.
2. Equation Group / Shadow Brokers Leak (2016-2017)
توضیح: گروه Shadow Brokers مجموعه ابزارهای هک متعلق به Equation Group (منسوب به NSA) را افشا کرد. ابزارهای مانند EternalBlue، DoublePulsar و غیره.
پیامد: رخدادهایی مانند حمله WannaCry، NotPetya و ظهور exploitation گسترده SMB.
3. Cobalt Strike Leaks
توضیح: ابزار Cobalt Strike یکی از محبوبترین فریم ورکهای C2 Red Team است که بارها نسخه کرکشده یا لو رفته آن در دارکوب و فرومها پخش شده است.
پیامد: حضور گسترده مهاجمان حرفهای، باجافزارها و گروههای APT در حملات واقعی با استفاده از نسخههای afk و obfuscated.
4. Brute Ratel Leak (2022)
توضیح: Brute Ratel یک ابزار C2 بسیار پیشرفته و ضدشناسایی است که پس از مدت کوتاهی از عرضه رسمی، نسخهای از آن نشت پیدا کرد و در اختیار مهاجمان (حتی باجافزار) قرار گرفت.
پیامد: بالا رفتن قابلیت فرار از EDR/AV، حملات بسیار پیشرفته و دشواری کشف.
5. Mythic & Other C2 Frameworks
توضیح: ابزار Mythic (اپنسورس اما غیرتجاری)، همچنین فریمورکهای C2 جدید نیز بارها قربانی نشت یا سواستفاده توسط مهاجمان شدهاند؛ گاهی حتی با «باینریهای شخصیسازیشده» (custom build) در حملات واقعی کشف شدهاند.
6. Shellter Elite Leak (2025)
توضیح: نشت نسخه تجاری Shellter Elite به دست مهاجمان و استفاده برای infostealer و bypass کردن EDRها.
دلایل و بسترهای نشت ابزارهای هک
۱. رخنه از سوی مشتریان نهایی (Buyers/Customers)
عدم رعایت OPSEC مشتری، سوءاستفاده عمدی، فروش مجدد در دارکوب
۲. هک شدن خود سازندهها (developer breach)
رخدادهایی مانند HackingTeam و ابزارهای NSA
۳. افزایش جذابیت مالی برای مجرمان
فروش نسخههای کرکشده یا منتقل شده در بدافزار-as-a-service
۴. جنگ سرد سایبری و اسپانسرهای ملی
بازیگران دولتی ابزارها را به صورت عمدی یا اتفاقی نشت میدهند
۵-عدم پیگیری قضایی کافی در برخی کشورها
تأثیر و پیامدهای عملیاتی نشت ابزارهای تجاری هک
-افزایش حملات سطح بالا و پیچیده
-گیج شدن تیمهای دفاعی و SOC(بدافزارها با امضای Red Team ساخته میشوند، خطاهای False negative و hunting سختتر میشود)
-شتاب رشد ضدشناسایی (evasion techniques)
-ضرورت همکاری بیشتر بین تیمهای توسعه ابزار و تیمهای تحلیل تهدید
-ظهور بازارهای جدید برای بدافزارهای ناشی از این ابزارها
رویکردهای دفاعی برای SOC و مدیران امنیت
1-بهروز نگهداشتن TI و IOC
توجه ویژه به تحلیلهای فنی در مورد نسخههای afk یا لو رفته ابزارها
2-برقراری تماس مستقیم با سازندگان ابزارها برای هشداردهی و رفع تهدید
3-توسعه Playbookهای Incident Response مخصوص ابزارهای مشهور نشت یافته
4-بهرهگیری از Telemetry و رفتارشناسی (Behavioral Analytics به جای صرف امضا)
5-آموزش تیمهای Blue Team با سناریوهای واقعی حمله Red Tool لو رفته
6-شناساگرهای memory-based و شبکه محور، به جای شناسایی صرف باینری
#آکادمی_روزبه
مرکز تخصصی CISSP
(از Red Team تا سلاح واقعی نزد مهاجمان)
مقدمه
در سالهای اخیر، موجی از نشت و افشای ابزارهای حرفهای و تجاری هک و Red Team به دست هکرها و مهاجمان واقعی افتاده است. ابزارهایی که اساساً با هدف تست نفوذ قانونی، ارزیابی امنیت سازمانها و آموزش نیروهای امنیتی توسعه یافتهاند، پس از نشت، به سلاحهای مورد علاقه مهاجمان برای طراحی حملات واقعی تبدیل شدهاند. این وقایع، چالشهای تازهای برای تیمهای SOC و عملیات دفاعی به همراه آورده است.
موارد مشهور نشت ابزارهای هک (Timeline)
1. Hacking Team Leak (2015)
توضیح: شرکت ایتالیایی Hacking Team تولیدکننده نرمافزار نظارتی RCS Galileo بود. در سال ۲۰۱۵، نزدیک به ۴۰۰ گیگابایت داده شامل سورسکد و exploit به صورت عمومی نشت یافت.
پیامد: آسیبپذیریهای zero-day، ابزارهای C2 و exploitها به صورت گسترده مورد سوءاستفاده مهاجمان از جمله APTها قرار گرفت.
2. Equation Group / Shadow Brokers Leak (2016-2017)
توضیح: گروه Shadow Brokers مجموعه ابزارهای هک متعلق به Equation Group (منسوب به NSA) را افشا کرد. ابزارهای مانند EternalBlue، DoublePulsar و غیره.
پیامد: رخدادهایی مانند حمله WannaCry، NotPetya و ظهور exploitation گسترده SMB.
3. Cobalt Strike Leaks
توضیح: ابزار Cobalt Strike یکی از محبوبترین فریم ورکهای C2 Red Team است که بارها نسخه کرکشده یا لو رفته آن در دارکوب و فرومها پخش شده است.
پیامد: حضور گسترده مهاجمان حرفهای، باجافزارها و گروههای APT در حملات واقعی با استفاده از نسخههای afk و obfuscated.
4. Brute Ratel Leak (2022)
توضیح: Brute Ratel یک ابزار C2 بسیار پیشرفته و ضدشناسایی است که پس از مدت کوتاهی از عرضه رسمی، نسخهای از آن نشت پیدا کرد و در اختیار مهاجمان (حتی باجافزار) قرار گرفت.
پیامد: بالا رفتن قابلیت فرار از EDR/AV، حملات بسیار پیشرفته و دشواری کشف.
5. Mythic & Other C2 Frameworks
توضیح: ابزار Mythic (اپنسورس اما غیرتجاری)، همچنین فریمورکهای C2 جدید نیز بارها قربانی نشت یا سواستفاده توسط مهاجمان شدهاند؛ گاهی حتی با «باینریهای شخصیسازیشده» (custom build) در حملات واقعی کشف شدهاند.
6. Shellter Elite Leak (2025)
توضیح: نشت نسخه تجاری Shellter Elite به دست مهاجمان و استفاده برای infostealer و bypass کردن EDRها.
دلایل و بسترهای نشت ابزارهای هک
۱. رخنه از سوی مشتریان نهایی (Buyers/Customers)
عدم رعایت OPSEC مشتری، سوءاستفاده عمدی، فروش مجدد در دارکوب
۲. هک شدن خود سازندهها (developer breach)
رخدادهایی مانند HackingTeam و ابزارهای NSA
۳. افزایش جذابیت مالی برای مجرمان
فروش نسخههای کرکشده یا منتقل شده در بدافزار-as-a-service
۴. جنگ سرد سایبری و اسپانسرهای ملی
بازیگران دولتی ابزارها را به صورت عمدی یا اتفاقی نشت میدهند
۵-عدم پیگیری قضایی کافی در برخی کشورها
تأثیر و پیامدهای عملیاتی نشت ابزارهای تجاری هک
-افزایش حملات سطح بالا و پیچیده
-گیج شدن تیمهای دفاعی و SOC(بدافزارها با امضای Red Team ساخته میشوند، خطاهای False negative و hunting سختتر میشود)
-شتاب رشد ضدشناسایی (evasion techniques)
-ضرورت همکاری بیشتر بین تیمهای توسعه ابزار و تیمهای تحلیل تهدید
-ظهور بازارهای جدید برای بدافزارهای ناشی از این ابزارها
رویکردهای دفاعی برای SOC و مدیران امنیت
1-بهروز نگهداشتن TI و IOC
توجه ویژه به تحلیلهای فنی در مورد نسخههای afk یا لو رفته ابزارها
2-برقراری تماس مستقیم با سازندگان ابزارها برای هشداردهی و رفع تهدید
3-توسعه Playbookهای Incident Response مخصوص ابزارهای مشهور نشت یافته
4-بهرهگیری از Telemetry و رفتارشناسی (Behavioral Analytics به جای صرف امضا)
5-آموزش تیمهای Blue Team با سناریوهای واقعی حمله Red Tool لو رفته
6-شناساگرهای memory-based و شبکه محور، به جای شناسایی صرف باینری
#آکادمی_روزبه
مرکز تخصصی CISSP
❤6
آشنایی با ابزارهای تجاری تیم قرمز
ابزار SHELLTER چگونه امنیت را دور میزند؟
۱. تزریق پویای بدافزار (Dynamic Shellcode Injection)
ابزار Shellter فایل اجرایی (exe) سالم و معتبری را برمیدارد و کد مخرب را به صورت داینامیک داخل آن تزریق میکند.
نقاط ورود (Entry point) را طوری تغییر میدهد که ابتدا کد خودش اجرا شود بعد برنامه اصلی.
این روش باعث میشود فایل نهایی از نظر ظاهری سالم و مثل فایل واقعی به نظر بیاید، حتی امضا (signature) و متادیتا هم حفظ میشود❗
۲. کد مخفی و تغییرشونده (Polymorphic Obfuscation)
کد مخرب دائماً خودش را تغییر میدهد (Polymorphic/Junk code) تا هیچ Signature ثابتی برای تشخیص وجود نداشته باشد.
ترکیبی از دستورات بیمعنی (NOPها، دستورات بیاثر) و تغییر ساختار shellcode باعث گیج شدن ابزارهای تحلیل و AV میشود.
۳. بارگذاری مرحلهای و رمزنگاری شده (Staged & Encrypted Payload)
کد مرحلهای (Staged): مرحله اول فقط loader است، اصل بدافزار بعداً و با شرایط خاص decrypt و اجرا میشود.
محتوا اکثراً Encode یا Encrypt شده. تا موقع اجرا شدن، چیزی از بدافزار به چشم AV نمیآید.
۴. استفاده از APIهای معمولی و رفتار عادی سیستم (Living off the Land)
برای اختصاص حافظه و اجرای shellcode، دقیقاً مثل نرمافزارهای معمول از APIهای ویندوز مثل VirtualAlloc و CreateFileMapping استفاده میکند.
در نتیجه، رفتار آن خیلی به برنامههای قانونی شبیه است و hunting مبتنی بر رفتار (behavioral detection) نیز چالش دارد.
۵. فرار از تحلیل استاتیک و دینامیک (Static & Dynamic Evasion)
با افزودن لایههای junk code و rerouting execution، ابزارهای تحلیل مثل IDA Pro یا Sandbox را گمراه میکند.
حتی بعضی نسخهها محیط اجرا را چک میکنند (Anti-VM)، اگر Sandbox یا VM باشد، اجرا نمیشوند یا رفتار جعلی نشان میدهند.
خلاصه ای بود از مقاله الستیک در لینک زیر
#آکادمی_روزبه
مرکز تخصصی CISSP
https://www.elastic.co/security-labs/taking-shellter?linkId=836491490
ابزار SHELLTER چگونه امنیت را دور میزند؟
۱. تزریق پویای بدافزار (Dynamic Shellcode Injection)
ابزار Shellter فایل اجرایی (exe) سالم و معتبری را برمیدارد و کد مخرب را به صورت داینامیک داخل آن تزریق میکند.
نقاط ورود (Entry point) را طوری تغییر میدهد که ابتدا کد خودش اجرا شود بعد برنامه اصلی.
این روش باعث میشود فایل نهایی از نظر ظاهری سالم و مثل فایل واقعی به نظر بیاید، حتی امضا (signature) و متادیتا هم حفظ میشود❗
۲. کد مخفی و تغییرشونده (Polymorphic Obfuscation)
کد مخرب دائماً خودش را تغییر میدهد (Polymorphic/Junk code) تا هیچ Signature ثابتی برای تشخیص وجود نداشته باشد.
ترکیبی از دستورات بیمعنی (NOPها، دستورات بیاثر) و تغییر ساختار shellcode باعث گیج شدن ابزارهای تحلیل و AV میشود.
۳. بارگذاری مرحلهای و رمزنگاری شده (Staged & Encrypted Payload)
کد مرحلهای (Staged): مرحله اول فقط loader است، اصل بدافزار بعداً و با شرایط خاص decrypt و اجرا میشود.
محتوا اکثراً Encode یا Encrypt شده. تا موقع اجرا شدن، چیزی از بدافزار به چشم AV نمیآید.
۴. استفاده از APIهای معمولی و رفتار عادی سیستم (Living off the Land)
برای اختصاص حافظه و اجرای shellcode، دقیقاً مثل نرمافزارهای معمول از APIهای ویندوز مثل VirtualAlloc و CreateFileMapping استفاده میکند.
در نتیجه، رفتار آن خیلی به برنامههای قانونی شبیه است و hunting مبتنی بر رفتار (behavioral detection) نیز چالش دارد.
۵. فرار از تحلیل استاتیک و دینامیک (Static & Dynamic Evasion)
با افزودن لایههای junk code و rerouting execution، ابزارهای تحلیل مثل IDA Pro یا Sandbox را گمراه میکند.
حتی بعضی نسخهها محیط اجرا را چک میکنند (Anti-VM)، اگر Sandbox یا VM باشد، اجرا نمیشوند یا رفتار جعلی نشان میدهند.
خلاصه ای بود از مقاله الستیک در لینک زیر
#آکادمی_روزبه
مرکز تخصصی CISSP
https://www.elastic.co/security-labs/taking-shellter?linkId=836491490
www.elastic.co
Taking SHELLTER: a commercial evasion framework abused in-the-wild
Elastic Security Labs detected the recent emergence of infostealers using an illicitly acquired version of the commercial evasion framework, SHELLTER, to deploy post-exploitation payloads.
❤5
جناب ملک نژاد ؛ امنیت یا شفافیت ؟
خروجی اگر ترور باشد دیگر شفافیت معنا ندارد
برادر من؛ با جان مردم بازی میکردی و امنیت کشور دست شما بوده
#آکادمی_روزبه
مرکز تخصصی CISSP
خروجی اگر ترور باشد دیگر شفافیت معنا ندارد
برادر من؛ با جان مردم بازی میکردی و امنیت کشور دست شما بوده
#آکادمی_روزبه
مرکز تخصصی CISSP
💯16
آکادمی آموزش روزبه 📚
جناب ملک نژاد ؛ امنیت یا شفافیت ؟ خروجی اگر ترور باشد دیگر شفافیت معنا ندارد برادر من؛ با جان مردم بازی میکردی و امنیت کشور دست شما بوده #آکادمی_روزبه مرکز تخصصی CISSP
👆👆🛑نقد عملکرد استارتاپ رسمیو
یکی از چالشیترین تقاطعهای امنیت اطلاعات، حریم خصوصی و دسترسی آزاد به دادهها در خصوص عملکرد شرکت رسمیو میتواند موضوع بحث باشد، که اتفاقاً مشابه همین مباحث در بسیاری از کشورها (مانند عدالتِ دادهها و توازن امنیت-شفافیت) مطرح شده است.
بیایید موضوع را از دو بخش بررسی کنیم: تحلیل انتقادی پروژه رسمیو و مفهوم آن در امنیت اطلاعات.
⚖️ ۱) تحلیل انتقادی عملکرد رسمیو
الف) مزایا و انگیزهها
رسمیو با جمعآوری دادهها (کراول، ترکیب منابع پراکنده، بازیابی دادههای حذفشده یا ناقص) شفافیت بالاتری برای کسبوکارها ایجاد کرده است، مثلاً دسترسی به سوابق شرکتها، مدیران، و… که به شفافیت اقتصادی و اعتبارسنجی کمک میکند.
دادههای ثانویهای که روزنامه رسمی عمداً پنهان/حذف میکند را بازتولید یا ترکیب کرده است؛ این برای برخی گردشهای مالی و تصمیمگیری تجاری یک مزیت است.
ب) نقاط منفی و نقدهای امنیتی
حریم خصوصی افراد: علت اصلی حذف بخشی از دادهها توسط روزنامه رسمی، محافظت از اشخاص مهم بوده است: جلوگیری از شناسایی آسان مدیران ارشد، قضات، و… (بهویژه در مورد پروندههای ویژه یا پرخطر).
رسمیو با بازسازی و انتشار این دادهها، عملاً اقدامات روزنامه رسمی برای پنهانسازی یا حداقلسازی ریسک هدف قرار گرفتن افراد مهم را خنثی کرده است.
این موضوع میتواند تهدیدهایی مثل حملات مهندسی اجتماعی، سوءاستفاده دزدان هویت، اختلال خدمات، یا حتی سناریوهای ترور یا اخاذی (بخصوص برای مدیران سطح بالا و پرخطر) و حتی ترور را افزایش دهد.
مسئلهی مطابقت با قوانین حمایت از دادهها (مثلاً GDPR معادل داخلی آن)، شفافیت در اعلام منبع داده، رضایت افراد و حذف پروفایل در صورت اعتراض، هم مطرح است.
🔐 ۲) دستهبندی این بحث در حوزه امنیت اطلاعات
در طبقهبندی کلاسیک امنیت اطلاعات، این موضوع در قالب مفاهیم زیر قابل تحلیل است:
۱. Privacy vs. Security
جمعآوری و انتشار اطلاعات افراد (خصوصاً افراد پرخطر) بدون رعایت حداقل الزامات حفاظت از حریم خصوصی یا رضایت، در “بازی با مرز امنیت و شفافیت” قرار میگیرد.
۲. Threat Intelligence Exposure
فراهمسازی اطلاعات شناساییشده در سطح وسیع برای افراد خاص (VIP Exposure) عملاً به مخاطره انداختن OPSEC آنها (Operations Security: امنیت عملیات) است.
در مدل VIP Threat Modeling، هرگونه data aggregation که موقعیت، آدرس یا روابط قدرت را آشکارتر کند، یک تهدید محسوب میشود.
۳. Data Aggregation Risks
رویکرد رسمیو با کنار هم گذاشتن دادههای پراکنده و ساختن پروفایل جامع، یک نمونه مشخص از aggregation threat است؛ یعنی خطری که در تئوری امنیت اطلاعات با عنوان “aggregation vulnerability” شناخته میشود.
۴. Legal & Ethical Considerations
در جمعآوری، نگهداری و افشای دادهها، بحثهای قانونی (data protection law) و اخلاقی (سود عامه در مقابل آسیب به فرد) هم مطرح است که فراتر از حوزه فنی صرف است.
📋 جمعبندی و توصیه
قابل نقد بودن: عملکرد رسمیو از منظر امنیت اطلاعات، به خصوص در حوزه حفاظت از شخصیتهای حساس (VIP Protection) و حداقلسازی حملات هدفمند و ترور قابل نقد جدی است. هر پروژه Aggregator باید مکانیزمهای حذف دادههای حساس، امکان opt-out برای اشخاص و ارزیابی ریسک داشته باشد.
موضوع امنیتی: این بحث در دستهی OPSEC (امنیت عملیات)، Aggregation Risk و VIP Threat Modeling قرار میگیرد.
توصیه: لازم است رسمیو و پروژههایی از این جنس، علاوه بر رعایت قانون و دسته بندی اطلاعات ، یک چارچوب ethical و حداقل یک مکانیزم درخواست حذف (Right to be Forgotten) برای دادههای حساس پیادهسازی کنند؛ و همچنین با نهادهای مسئول هماهنگ باشند.
#آکادمی_روزبه
مرکز تخصصی CISSP
✴️این مطلب پیرو تصویر پست قبل به نگارش در آمده است
یکی از چالشیترین تقاطعهای امنیت اطلاعات، حریم خصوصی و دسترسی آزاد به دادهها در خصوص عملکرد شرکت رسمیو میتواند موضوع بحث باشد، که اتفاقاً مشابه همین مباحث در بسیاری از کشورها (مانند عدالتِ دادهها و توازن امنیت-شفافیت) مطرح شده است.
بیایید موضوع را از دو بخش بررسی کنیم: تحلیل انتقادی پروژه رسمیو و مفهوم آن در امنیت اطلاعات.
⚖️ ۱) تحلیل انتقادی عملکرد رسمیو
الف) مزایا و انگیزهها
رسمیو با جمعآوری دادهها (کراول، ترکیب منابع پراکنده، بازیابی دادههای حذفشده یا ناقص) شفافیت بالاتری برای کسبوکارها ایجاد کرده است، مثلاً دسترسی به سوابق شرکتها، مدیران، و… که به شفافیت اقتصادی و اعتبارسنجی کمک میکند.
دادههای ثانویهای که روزنامه رسمی عمداً پنهان/حذف میکند را بازتولید یا ترکیب کرده است؛ این برای برخی گردشهای مالی و تصمیمگیری تجاری یک مزیت است.
ب) نقاط منفی و نقدهای امنیتی
حریم خصوصی افراد: علت اصلی حذف بخشی از دادهها توسط روزنامه رسمی، محافظت از اشخاص مهم بوده است: جلوگیری از شناسایی آسان مدیران ارشد، قضات، و… (بهویژه در مورد پروندههای ویژه یا پرخطر).
رسمیو با بازسازی و انتشار این دادهها، عملاً اقدامات روزنامه رسمی برای پنهانسازی یا حداقلسازی ریسک هدف قرار گرفتن افراد مهم را خنثی کرده است.
این موضوع میتواند تهدیدهایی مثل حملات مهندسی اجتماعی، سوءاستفاده دزدان هویت، اختلال خدمات، یا حتی سناریوهای ترور یا اخاذی (بخصوص برای مدیران سطح بالا و پرخطر) و حتی ترور را افزایش دهد.
مسئلهی مطابقت با قوانین حمایت از دادهها (مثلاً GDPR معادل داخلی آن)، شفافیت در اعلام منبع داده، رضایت افراد و حذف پروفایل در صورت اعتراض، هم مطرح است.
🔐 ۲) دستهبندی این بحث در حوزه امنیت اطلاعات
در طبقهبندی کلاسیک امنیت اطلاعات، این موضوع در قالب مفاهیم زیر قابل تحلیل است:
۱. Privacy vs. Security
جمعآوری و انتشار اطلاعات افراد (خصوصاً افراد پرخطر) بدون رعایت حداقل الزامات حفاظت از حریم خصوصی یا رضایت، در “بازی با مرز امنیت و شفافیت” قرار میگیرد.
۲. Threat Intelligence Exposure
فراهمسازی اطلاعات شناساییشده در سطح وسیع برای افراد خاص (VIP Exposure) عملاً به مخاطره انداختن OPSEC آنها (Operations Security: امنیت عملیات) است.
در مدل VIP Threat Modeling، هرگونه data aggregation که موقعیت، آدرس یا روابط قدرت را آشکارتر کند، یک تهدید محسوب میشود.
۳. Data Aggregation Risks
رویکرد رسمیو با کنار هم گذاشتن دادههای پراکنده و ساختن پروفایل جامع، یک نمونه مشخص از aggregation threat است؛ یعنی خطری که در تئوری امنیت اطلاعات با عنوان “aggregation vulnerability” شناخته میشود.
۴. Legal & Ethical Considerations
در جمعآوری، نگهداری و افشای دادهها، بحثهای قانونی (data protection law) و اخلاقی (سود عامه در مقابل آسیب به فرد) هم مطرح است که فراتر از حوزه فنی صرف است.
📋 جمعبندی و توصیه
قابل نقد بودن: عملکرد رسمیو از منظر امنیت اطلاعات، به خصوص در حوزه حفاظت از شخصیتهای حساس (VIP Protection) و حداقلسازی حملات هدفمند و ترور قابل نقد جدی است. هر پروژه Aggregator باید مکانیزمهای حذف دادههای حساس، امکان opt-out برای اشخاص و ارزیابی ریسک داشته باشد.
موضوع امنیتی: این بحث در دستهی OPSEC (امنیت عملیات)، Aggregation Risk و VIP Threat Modeling قرار میگیرد.
توصیه: لازم است رسمیو و پروژههایی از این جنس، علاوه بر رعایت قانون و دسته بندی اطلاعات ، یک چارچوب ethical و حداقل یک مکانیزم درخواست حذف (Right to be Forgotten) برای دادههای حساس پیادهسازی کنند؛ و همچنین با نهادهای مسئول هماهنگ باشند.
#آکادمی_روزبه
مرکز تخصصی CISSP
✴️این مطلب پیرو تصویر پست قبل به نگارش در آمده است
👏6
آکادمی آموزش روزبه 📚
👆👆🛑نقد عملکرد استارتاپ رسمیو یکی از چالشیترین تقاطعهای امنیت اطلاعات، حریم خصوصی و دسترسی آزاد به دادهها در خصوص عملکرد شرکت رسمیو میتواند موضوع بحث باشد، که اتفاقاً مشابه همین مباحث در بسیاری از کشورها (مانند عدالتِ دادهها و توازن امنیت-شفافیت) مطرح…
نقدی بر انتقاد به نقد من به رسمیو
در یک نگاه کلی، استدلال «چون اطلاعات پراکنده در وب هست، پس ایراد گرفتن از جمعکننده (رسمیو) بیمعناست» یک مغالطهی رایج به نام «طبیعیسازی» (Appeal to Nature) یا «چون فلان چیز وجود دارد پس استفاده از آن ایرادی ندارد» است. در عمل اما چند نکته کلیدی هست که همچنان نقد من را معتبر و حتی ضروری میکند:
تجمیع (Aggregation) ریسک را چند برابر میکند
هر تکه داده بهتنهایی شاید کمخطر باشد، اما وقتی با سایر دادهها ترکیب شود، پروفایلی جامع و بسیار حساس ساخته میشود.
این همان «aggregation vulnerability» است: چیزی که در حالت پراکنده به سادگی قابل سوءاستفاده نیست، پس از جمعآوری هوشمندانه به یک بردار حمله قدرتمند بدل میشود.
«دسترسی عمومی» ≠ «استفاده بیحد و مرز»
صرفِ اینکه یک سند یا دادهای در سایتهای مختلف پیدا میشود، به معنای مجوز نشر دوباره و بیقید و شرط آن نیست.
اصول GDPR و قوانین داخلی مشابه میگویند حتی برای دادههایی که «عمومی» تلقی میشوند، باید مبنای قانونی (مثل رضایت موضوع داده یا ملاحظات موجه عمومی) وجود داشته باشد.
مسئولیتهای اخلاقی و OPSEC
روزنامه رسمی با حذف یا عدم انتشار برخی فیلدها (مکان، آدرس منزل، روابط نزدیک با افراد پرخطر و …)، عمداً یک لایه حداقلی حفاظتی برای VIPها و قضات و … ایجاد میکند.
وقتی استارتاپی مثل رسمیو آن لایه را خنثی میکند، مجدداً افراد را در معرض مهندسی اجتماعی، سرقت هویت یا حتی تهدیدهای فیزیکی قرار میدهد.
پروژههای aggregator وظیفه دارند مکانیزمهای کاهش مخاطره را پیاده کنند
امکان «درخواست حذف» (Right to be Forgotten)
فیلتر کردن خودکار اطلاعات حساس (آدرس منزل، شمارهی موبایل شخصی، سابقه پزشکی، و….)
اخطار به کاربر نهایی در مورد ریسکهای احتمالیِ دادههای حساس
شفافیت اقتصادی یا منافع کسبوکاری، اولویت را نباید بر حریم خصوصی و امنیت افراد بگذارد
حتی اگر شفافیت اقتصادی دستاورد خوبی باشد، باید بین «شفافیت برای عموم» و «افشای اطلاعات شخصی» تعادل برقرار شود.
بسیاری کشورها، از جمله اعضای اتحادیه اروپا، برای همین تعادل چارچوبهای قانونی و نظارتی تعریف کردهاند.
جمعبندی
استدلال «چون دادهها قبلاً آزاد بودند پس اشکالی ندارد» در سطح فلسفی یا منافع بیزینسی ممکن است قانعکننده باشد، اما در عمل نسبت به ریسک aggregation، مسئولیت قانونی/اخلاقی و نیاز به حفظ OPSEC افراد بسیار آسیبزننده است.
بنابراین نقد من کاملاً بهجا است: هر پروژهای که دادههای پراکنده را جمع میکند، باید سازوکارهای حذف اطلاعات حساس، اخذ رضایت و کنترل ریسک را حتماً در طراحی خود بگنجاند.
#آکادمی_روزبه
مرکز تخصصی CISSP
در یک نگاه کلی، استدلال «چون اطلاعات پراکنده در وب هست، پس ایراد گرفتن از جمعکننده (رسمیو) بیمعناست» یک مغالطهی رایج به نام «طبیعیسازی» (Appeal to Nature) یا «چون فلان چیز وجود دارد پس استفاده از آن ایرادی ندارد» است. در عمل اما چند نکته کلیدی هست که همچنان نقد من را معتبر و حتی ضروری میکند:
تجمیع (Aggregation) ریسک را چند برابر میکند
هر تکه داده بهتنهایی شاید کمخطر باشد، اما وقتی با سایر دادهها ترکیب شود، پروفایلی جامع و بسیار حساس ساخته میشود.
این همان «aggregation vulnerability» است: چیزی که در حالت پراکنده به سادگی قابل سوءاستفاده نیست، پس از جمعآوری هوشمندانه به یک بردار حمله قدرتمند بدل میشود.
«دسترسی عمومی» ≠ «استفاده بیحد و مرز»
صرفِ اینکه یک سند یا دادهای در سایتهای مختلف پیدا میشود، به معنای مجوز نشر دوباره و بیقید و شرط آن نیست.
اصول GDPR و قوانین داخلی مشابه میگویند حتی برای دادههایی که «عمومی» تلقی میشوند، باید مبنای قانونی (مثل رضایت موضوع داده یا ملاحظات موجه عمومی) وجود داشته باشد.
مسئولیتهای اخلاقی و OPSEC
روزنامه رسمی با حذف یا عدم انتشار برخی فیلدها (مکان، آدرس منزل، روابط نزدیک با افراد پرخطر و …)، عمداً یک لایه حداقلی حفاظتی برای VIPها و قضات و … ایجاد میکند.
وقتی استارتاپی مثل رسمیو آن لایه را خنثی میکند، مجدداً افراد را در معرض مهندسی اجتماعی، سرقت هویت یا حتی تهدیدهای فیزیکی قرار میدهد.
پروژههای aggregator وظیفه دارند مکانیزمهای کاهش مخاطره را پیاده کنند
امکان «درخواست حذف» (Right to be Forgotten)
فیلتر کردن خودکار اطلاعات حساس (آدرس منزل، شمارهی موبایل شخصی، سابقه پزشکی، و….)
اخطار به کاربر نهایی در مورد ریسکهای احتمالیِ دادههای حساس
شفافیت اقتصادی یا منافع کسبوکاری، اولویت را نباید بر حریم خصوصی و امنیت افراد بگذارد
حتی اگر شفافیت اقتصادی دستاورد خوبی باشد، باید بین «شفافیت برای عموم» و «افشای اطلاعات شخصی» تعادل برقرار شود.
بسیاری کشورها، از جمله اعضای اتحادیه اروپا، برای همین تعادل چارچوبهای قانونی و نظارتی تعریف کردهاند.
جمعبندی
استدلال «چون دادهها قبلاً آزاد بودند پس اشکالی ندارد» در سطح فلسفی یا منافع بیزینسی ممکن است قانعکننده باشد، اما در عمل نسبت به ریسک aggregation، مسئولیت قانونی/اخلاقی و نیاز به حفظ OPSEC افراد بسیار آسیبزننده است.
بنابراین نقد من کاملاً بهجا است: هر پروژهای که دادههای پراکنده را جمع میکند، باید سازوکارهای حذف اطلاعات حساس، اخذ رضایت و کنترل ریسک را حتماً در طراحی خود بگنجاند.
#آکادمی_روزبه
مرکز تخصصی CISSP
👏10
وقتی میگویم در SOC دقیق باشیم یعنی چه؟
** از مجموعه مقالات : آنچه SOC های ایران بدان گرفتارند!!
وقتی یک هشدار اجرای مشکوک PowerShell را در سامانهی اسپلانک مشاهده میکنید، اگر به آن فقط به عنوان یک Event جداگانه نگاه کنید، میزان واقعی تهدید را درک نخواهید کرد. اما با تحلیل هوشمند و ردیابی زنجیره حمله، میتوانید سناریوهای چندمرحلهای و پیچیده را شناسایی کنید—که این دقیقاً همان نقطه تمایز یک SOC حرفهای مبتنی بر Threat Hunting نسبت به SOCهای صرفاً قاعدهمحور است.
مثال :
فرض کنید مهاجم ابتدا با یک آسیبپذیری در Exchange Server کد PowerShell را اجرا میکند (Initial Access و Execution). فقط این هشدار ثبت میشود:
powershell.exe -EncodedCommand <base64>
در نگاه اول، شاید این فقط اجرای یک اسکریپت باشد. اما با بررسی دقیقتر متوجه میشوید که:
ساعتی بعد، یک Scheduled Task جدید روی همان سرور ساخته شده (schtasks.exe /create ...)، که به PowerShell اشاره دارد (Persistence)
همزمان یک ارتباط Reverse Shell به سمت IP ناشناس در اینترنت برقرار شده (Command & Control)
فایلهای لاگ در آن سرور توسط یک اسکریپت پاکسازی یا تغییر یافتهاند (Defense Evasion)
نهایتاً چهار روز بعد، روی یکی از سرورهای Domain Controller همان نشانههای رفتاری (PowerShell، Task scheduling، ارتباط به خارج) دیده میشود (Lateral Movement & Privilege Escalation)
در این وضعیت، صرفاً داشتن یک rule ساده که بگوید «هر اجرای مشکوک PowerShell را هشدار بده» راهگشا نیست. یک هانتر (Threat Hunter) واقعی، این سیگنالهای پراکنده را به هم متصل میکند و میتواند زنجیره حمله (Kill Chain) را شناسایی و جلوی گسترش آن را در مراحل ابتدایی بگیرد.
در عمل، این شیوه تحلیل، SOC شما را از یک مرکز هشداردهی منفعل، به یک تیم شکار تهدید فعال و هوشمند ارتقا میدهد—جایی که شناسایی اجرای اولیه، دور زدن مکانیزمهای دفاعی و ایجاد ماندگاری مهاجم، همزمان کشف و مهار میشود. این همان تفاوت کار SOC حرفهای با رویکرد threat hunting و توسعهیافته نسبت به rule-based analysis است
#آکادمی_روزبه
مرکز تخصصی CISSP
** از مجموعه مقالات : آنچه SOC های ایران بدان گرفتارند!!
وقتی یک هشدار اجرای مشکوک PowerShell را در سامانهی اسپلانک مشاهده میکنید، اگر به آن فقط به عنوان یک Event جداگانه نگاه کنید، میزان واقعی تهدید را درک نخواهید کرد. اما با تحلیل هوشمند و ردیابی زنجیره حمله، میتوانید سناریوهای چندمرحلهای و پیچیده را شناسایی کنید—که این دقیقاً همان نقطه تمایز یک SOC حرفهای مبتنی بر Threat Hunting نسبت به SOCهای صرفاً قاعدهمحور است.
مثال :
فرض کنید مهاجم ابتدا با یک آسیبپذیری در Exchange Server کد PowerShell را اجرا میکند (Initial Access و Execution). فقط این هشدار ثبت میشود:
powershell.exe -EncodedCommand <base64>
در نگاه اول، شاید این فقط اجرای یک اسکریپت باشد. اما با بررسی دقیقتر متوجه میشوید که:
ساعتی بعد، یک Scheduled Task جدید روی همان سرور ساخته شده (schtasks.exe /create ...)، که به PowerShell اشاره دارد (Persistence)
همزمان یک ارتباط Reverse Shell به سمت IP ناشناس در اینترنت برقرار شده (Command & Control)
فایلهای لاگ در آن سرور توسط یک اسکریپت پاکسازی یا تغییر یافتهاند (Defense Evasion)
نهایتاً چهار روز بعد، روی یکی از سرورهای Domain Controller همان نشانههای رفتاری (PowerShell، Task scheduling، ارتباط به خارج) دیده میشود (Lateral Movement & Privilege Escalation)
در این وضعیت، صرفاً داشتن یک rule ساده که بگوید «هر اجرای مشکوک PowerShell را هشدار بده» راهگشا نیست. یک هانتر (Threat Hunter) واقعی، این سیگنالهای پراکنده را به هم متصل میکند و میتواند زنجیره حمله (Kill Chain) را شناسایی و جلوی گسترش آن را در مراحل ابتدایی بگیرد.
در عمل، این شیوه تحلیل، SOC شما را از یک مرکز هشداردهی منفعل، به یک تیم شکار تهدید فعال و هوشمند ارتقا میدهد—جایی که شناسایی اجرای اولیه، دور زدن مکانیزمهای دفاعی و ایجاد ماندگاری مهاجم، همزمان کشف و مهار میشود. این همان تفاوت کار SOC حرفهای با رویکرد threat hunting و توسعهیافته نسبت به rule-based analysis است
#آکادمی_روزبه
مرکز تخصصی CISSP
❤6
ISO_IEC 27031_2025.pdf
1.1 MB
مستندی که در جلسه اول دوره مدیریت بحران سایبری بررسی شد
✅ثبت نام دوره بعدی
از طریق واتس اپ و بله 09902857290
برگزاری دوره با تسهیلات ویژه شرکت هامون
#آکادمی_روزبه
مرکز تخصصی CISSP
جلسه دوم بحث عملیات فنی فارنزیک رو داریم
✅ثبت نام دوره بعدی
از طریق واتس اپ و بله 09902857290
برگزاری دوره با تسهیلات ویژه شرکت هامون
#آکادمی_روزبه
مرکز تخصصی CISSP
جلسه دوم بحث عملیات فنی فارنزیک رو داریم
👍3❤2
متریک ها در امنیت سایبری
چیستی و اهمیت
روزبه نوروزی
Www.Roozbeh.academy
متریک: دقیقا چه میکنیم و آیا خوب عمل میکنیم؟
چرا متریکها در امنیت سایبری حیاتی هستند؟
یک جمله معروف در مدیریت میگوید: “اگر نتوانی چیزی را اندازهگیری کنی، نمیتوانی آن را بهبود ببخشی.” این جمله دقیقاً قلب اهمیت متریکها در امنیت سایبری است. بدون اندازهگیری، تیمهای امنیتی در تاریکی عمل میکنند و نمیدانند تلاشهایشان چقدر مؤثر است، کجا ضعف دارند و منابع خود را باید در کجا سرمایهگذاری کنند.
دلایل کلیدی اهمیت متریکها عبارتند از:
1. ایجاد شفافیت و درک وضعیت فعلی (Visibility):
متریکها وضعیت واقعی امنیت سازمان شما را به تصویر میکشند. به جای اینکه بگویید “فکر میکنم وضعیت امنیتی ما خوب است”، میتوانید با داده صحبت کنید: “در ماه گذشته، تعداد آسیبپذیریهای حیاتی ما 15% کاهش یافته است.” این شفافیت به شما کمک میکند تا نقاط قوت و ضعف واقعی خود را بشناسید.
2. تصمیمگیری مبتنی بر داده (Data-Driven Decision Making):
🎯 به جای خرید جدیدترین و گرانترین ابزار امنیتی چون مُد شده است، متریکها به شما کمک میکنند تا سرمایهگذاریهای خود را هوشمندانه انجام دهید. برای مثال، اگر متریکها نشان دهند که 80% از حوادث امنیتی شما ناشی از حملات فیشینگ است، منطقی است که بودجه بیشتری را به آموزش آگاهیبخشی کاربران و تقویت امنیت ایمیل اختصاص دهید تا خرید یک فایروال جدید.
3. سنجش پیشرفت و بازگشت سرمایه (Measuring Progress & ROI):
📈 چگونه میفهمید که ابزار جدیدی که خریدهاید یا کمپین آموزشی که برگزار کردهاید، مؤثر بوده است؟ با متریکها؛ شما میتوانید وضعیت را قبل و بعد از یک اقدام خاص مقایسه کنید. برای مثال، میتوانید “نرخ کلیک روی لینکهای فیشینگ شبیهسازی شده” را قبل و بعد از یک دوره آموزشی اندازهگیری کنید. این به شما کمک میکند تا بازگشت سرمایه (ROI) اقدامات امنیتی خود را به مدیران نشان دهید.
4. ارتباط مؤثر با مدیران و ذینفعان (Communication):
📊 مدیران ارشد و اعضای هیئت مدیره زبان فنی امنیت را متوجه نمیشوند، اما زبان اعداد، نمودارها و روندها را به خوبی درک میکنند. متریکها به شما این امکان را میدهند که ریسکهای امنیتی و نیازهای خود را به زبانی قابل فهم برای آنها ترجمه کنید. به جای گفتن “ما به یک سیستم SIEM نیاز داریم”، میتوانید بگویید: “در حال حاضر، میانگین زمان شناسایی یک نفوذ در شبکه ما 90 روز است. با پیادهسازی این سیستم، میتوانیم این زمان را به کمتر از 2424 ساعت کاهش دهیم و ریسک مالی ناشی از نشت اطلاعات راX% کم کنیم.”
5. انطباق با قوانین و استانداردها (Compliance):
بسیاری از مقررات و استانداردها (مانند GDPR، HIPAA یا PCI-DSS) سازمانها را ملزم میکنند تا نشان دهند که اقدامات امنیتی لازم را انجام دادهاند. متریکها بهترین مدرک برای اثبات این انطباق هستند. به عنوان مثال، میتوانید با ارائه متریک “پوشش اسکن آسیبپذیری” نشان دهید که 99% از داراییهای شبکه به طور منظم اسکن میشوند.
6. حرکت از رویکرد واکنشی به پیشگیرانه (Proactive vs. Reactive):
متریکها به شما کمک میکنند تا روندها را قبل از اینکه به یک بحران تبدیل شوند، شناسایی کنید. اگر میبینید که “تعداد تلاشهای ناموفق برای ورود به سیستم” به طور ناگهانی در حال افزایش است، میتوانید قبل از وقوع یک حمله موفق، اقدامات پیشگیرانه انجام دهید.
برخی از مهمترین متریکهای امنیت سایبری
متریکها باید هوشمندانه انتخاب شوند. جمعآوری صدها متریک بیفایده است. بهتر است روی تعداد کمی متریک کلیدی که مستقیماً با اهداف کسبوکار شما مرتبط هستند، تمرکز کنید. در اینجا برخی از مهمترین متریکها در دستهبندیهای مختلف آورده شدهاند:
🛡️ دسته ۱: مدیریت آسیبپذیری (Vulnerability Management)
این متریکها نشان میدهند که سازمان شما با چه سرعتی آسیبپذیریها را شناسایی و رفع میکند.
میانگین زمان رفع آسیبپذیری (Mean Time to Remediate - MTTR):
چه چیزی را اندازه میگیرد؟ میانگین زمان از لحظه شناسایی یک آسیبپذیری تا لحظهای که به طور کامل رفع (مثلاً با نصب پچ) میشود.
چرا مهم است؟ این یکی از حیاتیترین متریکهاست. هرچه این زمان کوتاهتر باشد، فرصت کمتری در اختیار مهاجمان برای سوءاستفاده از آن ضعف قرار میگیرد. معمولاً این متریک بر اساس شدت آسیبپذیری (حیاتی، بالا، متوسط) تفکیک میشود.
پوشش اسکن آسیبپذیری (Vulnerability Scan Coverage):
چه چیزی را اندازه میگیرد؟ چه درصدی از کل داراییهای شناختهشده (سرورها، لپتاپها، …) در سازمان به طور منظم توسط اسکنرهای آسیبپذیری بررسی میشوند.
پایان بخش اول
#آکادمی_روزبه
مرکز تخصصی CISSP
بخش دوم در پست بعد👇👇
چیستی و اهمیت
روزبه نوروزی
Www.Roozbeh.academy
متریک: دقیقا چه میکنیم و آیا خوب عمل میکنیم؟
چرا متریکها در امنیت سایبری حیاتی هستند؟
یک جمله معروف در مدیریت میگوید: “اگر نتوانی چیزی را اندازهگیری کنی، نمیتوانی آن را بهبود ببخشی.” این جمله دقیقاً قلب اهمیت متریکها در امنیت سایبری است. بدون اندازهگیری، تیمهای امنیتی در تاریکی عمل میکنند و نمیدانند تلاشهایشان چقدر مؤثر است، کجا ضعف دارند و منابع خود را باید در کجا سرمایهگذاری کنند.
دلایل کلیدی اهمیت متریکها عبارتند از:
1. ایجاد شفافیت و درک وضعیت فعلی (Visibility):
متریکها وضعیت واقعی امنیت سازمان شما را به تصویر میکشند. به جای اینکه بگویید “فکر میکنم وضعیت امنیتی ما خوب است”، میتوانید با داده صحبت کنید: “در ماه گذشته، تعداد آسیبپذیریهای حیاتی ما 15% کاهش یافته است.” این شفافیت به شما کمک میکند تا نقاط قوت و ضعف واقعی خود را بشناسید.
2. تصمیمگیری مبتنی بر داده (Data-Driven Decision Making):
🎯 به جای خرید جدیدترین و گرانترین ابزار امنیتی چون مُد شده است، متریکها به شما کمک میکنند تا سرمایهگذاریهای خود را هوشمندانه انجام دهید. برای مثال، اگر متریکها نشان دهند که 80% از حوادث امنیتی شما ناشی از حملات فیشینگ است، منطقی است که بودجه بیشتری را به آموزش آگاهیبخشی کاربران و تقویت امنیت ایمیل اختصاص دهید تا خرید یک فایروال جدید.
3. سنجش پیشرفت و بازگشت سرمایه (Measuring Progress & ROI):
📈 چگونه میفهمید که ابزار جدیدی که خریدهاید یا کمپین آموزشی که برگزار کردهاید، مؤثر بوده است؟ با متریکها؛ شما میتوانید وضعیت را قبل و بعد از یک اقدام خاص مقایسه کنید. برای مثال، میتوانید “نرخ کلیک روی لینکهای فیشینگ شبیهسازی شده” را قبل و بعد از یک دوره آموزشی اندازهگیری کنید. این به شما کمک میکند تا بازگشت سرمایه (ROI) اقدامات امنیتی خود را به مدیران نشان دهید.
4. ارتباط مؤثر با مدیران و ذینفعان (Communication):
📊 مدیران ارشد و اعضای هیئت مدیره زبان فنی امنیت را متوجه نمیشوند، اما زبان اعداد، نمودارها و روندها را به خوبی درک میکنند. متریکها به شما این امکان را میدهند که ریسکهای امنیتی و نیازهای خود را به زبانی قابل فهم برای آنها ترجمه کنید. به جای گفتن “ما به یک سیستم SIEM نیاز داریم”، میتوانید بگویید: “در حال حاضر، میانگین زمان شناسایی یک نفوذ در شبکه ما 90 روز است. با پیادهسازی این سیستم، میتوانیم این زمان را به کمتر از 2424 ساعت کاهش دهیم و ریسک مالی ناشی از نشت اطلاعات راX% کم کنیم.”
5. انطباق با قوانین و استانداردها (Compliance):
بسیاری از مقررات و استانداردها (مانند GDPR، HIPAA یا PCI-DSS) سازمانها را ملزم میکنند تا نشان دهند که اقدامات امنیتی لازم را انجام دادهاند. متریکها بهترین مدرک برای اثبات این انطباق هستند. به عنوان مثال، میتوانید با ارائه متریک “پوشش اسکن آسیبپذیری” نشان دهید که 99% از داراییهای شبکه به طور منظم اسکن میشوند.
6. حرکت از رویکرد واکنشی به پیشگیرانه (Proactive vs. Reactive):
متریکها به شما کمک میکنند تا روندها را قبل از اینکه به یک بحران تبدیل شوند، شناسایی کنید. اگر میبینید که “تعداد تلاشهای ناموفق برای ورود به سیستم” به طور ناگهانی در حال افزایش است، میتوانید قبل از وقوع یک حمله موفق، اقدامات پیشگیرانه انجام دهید.
برخی از مهمترین متریکهای امنیت سایبری
متریکها باید هوشمندانه انتخاب شوند. جمعآوری صدها متریک بیفایده است. بهتر است روی تعداد کمی متریک کلیدی که مستقیماً با اهداف کسبوکار شما مرتبط هستند، تمرکز کنید. در اینجا برخی از مهمترین متریکها در دستهبندیهای مختلف آورده شدهاند:
🛡️ دسته ۱: مدیریت آسیبپذیری (Vulnerability Management)
این متریکها نشان میدهند که سازمان شما با چه سرعتی آسیبپذیریها را شناسایی و رفع میکند.
میانگین زمان رفع آسیبپذیری (Mean Time to Remediate - MTTR):
چه چیزی را اندازه میگیرد؟ میانگین زمان از لحظه شناسایی یک آسیبپذیری تا لحظهای که به طور کامل رفع (مثلاً با نصب پچ) میشود.
چرا مهم است؟ این یکی از حیاتیترین متریکهاست. هرچه این زمان کوتاهتر باشد، فرصت کمتری در اختیار مهاجمان برای سوءاستفاده از آن ضعف قرار میگیرد. معمولاً این متریک بر اساس شدت آسیبپذیری (حیاتی، بالا، متوسط) تفکیک میشود.
پوشش اسکن آسیبپذیری (Vulnerability Scan Coverage):
چه چیزی را اندازه میگیرد؟ چه درصدی از کل داراییهای شناختهشده (سرورها، لپتاپها، …) در سازمان به طور منظم توسط اسکنرهای آسیبپذیری بررسی میشوند.
پایان بخش اول
#آکادمی_روزبه
مرکز تخصصی CISSP
بخش دوم در پست بعد👇👇
❤5👍3
👆👆قسمت دوم از پست قبل
چرا مهم است؟ اگر شما تنها 60% از داراییهای خود را اسکن کنید، 40% باقیمانده یک نقطه کور بزرگ و خطرناک است. هدف باید نزدیک به 100% باشد.
تعداد آسیبپذیریهای باز بر اساس شدت (Open Vulnerabilities by Severity):
چه چیزی را اندازه میگیرد؟ تعداد کل آسیبپذیریهای شناسایی شده که هنوز رفع نشدهاند، به تفکیک شدت
چرا مهم است؟ این متریک یک دید کلی از “بدهی امنیتی” سازمان به شما میدهد. هدف اصلی، به صفر رساندن تعداد آسیبپذیریهای حیاتی است.
🚨 دسته ۲: پاسخ به حوادث (Incident Response)
این متریکها کارایی تیم شما در شناسایی و مهار حملات را میسنجند.
میانگین زمان شناسایی (Mean Time to Detect - MTTD):
چه چیزی را اندازه میگیرد؟ میانگین زمان از لحظه وقوع یک نفوذ یا فعالیت مخرب تا لحظهای که توسط تیم امنیتی شناسایی میشود.
چرا مهم است؟ مهاجمان هرچه زمان بیشتری به صورت شناسایی نشده در شبکه شما باقی بمانند، خسارت بیشتری وارد میکنند. کاهش این زمان یک اولویت اصلی برای هر تیم امنیتی است.
میانگین زمان پاسخ/مهار (Mean Time to Respond/Contain - MTTR):
چه چیزی را اندازه میگیرد؟ میانگین زمان از لحظه شناسایی یک حادثه تا لحظهای که مهار شده و از گسترش آن جلوگیری میشود.
چرا مهم است؟ سرعت عمل در این مرحله میتواند تفاوت بین یک حادثه کوچک و یک فاجعه تمامعیار باشد.
تعداد حوادث امنیتی (Number of Security Incidents):
چه چیزی را اندازه میگیرد؟ تعداد کل حوادث امنیتی در یک دوره زمانی مشخص (مثلاً ماهانه یا فصلی)، که معمولاً بر اساس نوع یا شدت دستهبندی میشوند.
چرا مهم است؟ رصد روند این متریک به شما نشان میدهد که آیا اقدامات پیشگیرانه شما در حال کاهش تعداد حملات موفق هستند یا خیر.
🧑🏫 دسته ۳: آگاهیبخشی و کاربران (User Awareness)
کاربران اغلب ضعیفترین حلقه در زنجیره امنیت هستند. این متریکها میزان آگاهی آنها را میسنجند.
نرخ کلیک در کمپینهای فیشینگ شبیهسازی شده (Phishing Simulation Click Rate):
چه چیزی را اندازه میگیرد؟ درصدی از کارمندان که روی لینکها یا پیوستهای ایمیلهای فیشینگ شبیهسازی شده کلیک میکنند.
چرا مهم است؟ این متریک یک شاخص مستقیم از میزان آگاهی کاربران و تأثیرگذاری برنامههای آموزشی است. هدف، کاهش مداوم این درصد است.
نرخ گزارش ایمیلهای مشکوک توسط کاربران (User-Reported Phishing Rate):
چه چیزی را اندازه میگیرد؟ تعداد ایمیلهای مشکوکی که کاربران به تیم امنیتی گزارش میدهند.
چرا مهم است؟ برخلاف تصور، افزایش این متریک یک نشانه مثبت است! این یعنی کاربران شما هوشیار شدهاند و به جای قربانی شدن، به عنوان یک “سنسور انسانی” برای تیم امنیتی عمل میکنند.
⚙️ دسته ۴: سلامت عملیات امنیتی (Security Operations Health)
این متریکها نشان میدهند که آیا ابزارها و فرآیندهای امنیتی شما به درستی کار میکنند یا خیر.
درصد سیستمهای منطبق با سیاستها (Policy Compliance):
چه چیزی را اندازه میگیرد؟ چه درصدی از سیستمها (مانند سرورها و لپتاپها) با استانداردهای امنیتی سازمان (مثلاً داشتن آنتیویروس بهروز، رمزگذاری دیسک، و …) مطابقت دارند.
چرا مهم است؟ این متریک به شما کمک میکند تا شکافهای ناشی از پیکربندیهای نادرست را شناسایی و رفع کنید.
آپتایم ابزارهای امنیتی (Security Tool Uptime):
چه چیزی را اندازه میگیرد؟ درصدی از زمان که ابزارهای حیاتی امنیتی شما (مانند فایروال، SIEM، EDR) فعال و در حال کار هستند.
چرا مهم است؟ یک ابزار امنیتی که خاموش است، هیچ ارزشی ندارد. هدف باید نزدیک به 100% باشد.
نتیجهگیری
متریکها ستون فقرات یک برنامه امنیت سایبری مدرن و بالغ هستند. آنها به سازمانها کمک میکنند تا:
از وضعیت واقعی خود آگاه شوند.
منابع خود را به صورت هوشمندانه تخصیص دهند.
ارزش سرمایهگذاریهای امنیتی را به مدیران نشان دهند.
به طور مداوم بهبود یابند و از رقبا و مهاجمان یک قدم جلوتر باشند.
مهمترین نکته این است که با چند متریک کلیدی و قابل اجرا شروع کنید، فرآیند جمعآوری داده را تا حد امکان خودکار کنید و به طور منظم این متریکها را بازبینی کرده و بر اساس آنها اقدام کنید.
#آکادمی_روزبه
مرکز تخصصی CISSP
Www.Roozbeh.academy
چرا مهم است؟ اگر شما تنها 60% از داراییهای خود را اسکن کنید، 40% باقیمانده یک نقطه کور بزرگ و خطرناک است. هدف باید نزدیک به 100% باشد.
تعداد آسیبپذیریهای باز بر اساس شدت (Open Vulnerabilities by Severity):
چه چیزی را اندازه میگیرد؟ تعداد کل آسیبپذیریهای شناسایی شده که هنوز رفع نشدهاند، به تفکیک شدت
چرا مهم است؟ این متریک یک دید کلی از “بدهی امنیتی” سازمان به شما میدهد. هدف اصلی، به صفر رساندن تعداد آسیبپذیریهای حیاتی است.
🚨 دسته ۲: پاسخ به حوادث (Incident Response)
این متریکها کارایی تیم شما در شناسایی و مهار حملات را میسنجند.
میانگین زمان شناسایی (Mean Time to Detect - MTTD):
چه چیزی را اندازه میگیرد؟ میانگین زمان از لحظه وقوع یک نفوذ یا فعالیت مخرب تا لحظهای که توسط تیم امنیتی شناسایی میشود.
چرا مهم است؟ مهاجمان هرچه زمان بیشتری به صورت شناسایی نشده در شبکه شما باقی بمانند، خسارت بیشتری وارد میکنند. کاهش این زمان یک اولویت اصلی برای هر تیم امنیتی است.
میانگین زمان پاسخ/مهار (Mean Time to Respond/Contain - MTTR):
چه چیزی را اندازه میگیرد؟ میانگین زمان از لحظه شناسایی یک حادثه تا لحظهای که مهار شده و از گسترش آن جلوگیری میشود.
چرا مهم است؟ سرعت عمل در این مرحله میتواند تفاوت بین یک حادثه کوچک و یک فاجعه تمامعیار باشد.
تعداد حوادث امنیتی (Number of Security Incidents):
چه چیزی را اندازه میگیرد؟ تعداد کل حوادث امنیتی در یک دوره زمانی مشخص (مثلاً ماهانه یا فصلی)، که معمولاً بر اساس نوع یا شدت دستهبندی میشوند.
چرا مهم است؟ رصد روند این متریک به شما نشان میدهد که آیا اقدامات پیشگیرانه شما در حال کاهش تعداد حملات موفق هستند یا خیر.
🧑🏫 دسته ۳: آگاهیبخشی و کاربران (User Awareness)
کاربران اغلب ضعیفترین حلقه در زنجیره امنیت هستند. این متریکها میزان آگاهی آنها را میسنجند.
نرخ کلیک در کمپینهای فیشینگ شبیهسازی شده (Phishing Simulation Click Rate):
چه چیزی را اندازه میگیرد؟ درصدی از کارمندان که روی لینکها یا پیوستهای ایمیلهای فیشینگ شبیهسازی شده کلیک میکنند.
چرا مهم است؟ این متریک یک شاخص مستقیم از میزان آگاهی کاربران و تأثیرگذاری برنامههای آموزشی است. هدف، کاهش مداوم این درصد است.
نرخ گزارش ایمیلهای مشکوک توسط کاربران (User-Reported Phishing Rate):
چه چیزی را اندازه میگیرد؟ تعداد ایمیلهای مشکوکی که کاربران به تیم امنیتی گزارش میدهند.
چرا مهم است؟ برخلاف تصور، افزایش این متریک یک نشانه مثبت است! این یعنی کاربران شما هوشیار شدهاند و به جای قربانی شدن، به عنوان یک “سنسور انسانی” برای تیم امنیتی عمل میکنند.
⚙️ دسته ۴: سلامت عملیات امنیتی (Security Operations Health)
این متریکها نشان میدهند که آیا ابزارها و فرآیندهای امنیتی شما به درستی کار میکنند یا خیر.
درصد سیستمهای منطبق با سیاستها (Policy Compliance):
چه چیزی را اندازه میگیرد؟ چه درصدی از سیستمها (مانند سرورها و لپتاپها) با استانداردهای امنیتی سازمان (مثلاً داشتن آنتیویروس بهروز، رمزگذاری دیسک، و …) مطابقت دارند.
چرا مهم است؟ این متریک به شما کمک میکند تا شکافهای ناشی از پیکربندیهای نادرست را شناسایی و رفع کنید.
آپتایم ابزارهای امنیتی (Security Tool Uptime):
چه چیزی را اندازه میگیرد؟ درصدی از زمان که ابزارهای حیاتی امنیتی شما (مانند فایروال، SIEM، EDR) فعال و در حال کار هستند.
چرا مهم است؟ یک ابزار امنیتی که خاموش است، هیچ ارزشی ندارد. هدف باید نزدیک به 100% باشد.
نتیجهگیری
متریکها ستون فقرات یک برنامه امنیت سایبری مدرن و بالغ هستند. آنها به سازمانها کمک میکنند تا:
از وضعیت واقعی خود آگاه شوند.
منابع خود را به صورت هوشمندانه تخصیص دهند.
ارزش سرمایهگذاریهای امنیتی را به مدیران نشان دهند.
به طور مداوم بهبود یابند و از رقبا و مهاجمان یک قدم جلوتر باشند.
مهمترین نکته این است که با چند متریک کلیدی و قابل اجرا شروع کنید، فرآیند جمعآوری داده را تا حد امکان خودکار کنید و به طور منظم این متریکها را بازبینی کرده و بر اساس آنها اقدام کنید.
#آکادمی_روزبه
مرکز تخصصی CISSP
Www.Roozbeh.academy
❤4🤝2
مدیر امنیت زیر نظر کی باشه؟
شاید زمان تغییر نظر فرا رسیده
**روزبه نوروزی
Www.Roozbeh.academy
مشکل سنتی: درگیری و تعارض منافع مدیر امنیت و مدیر IT
مدیر IT (مثلاً CTO یا IT Manager) وظیفهاش «کارایی، دسترسپذیری و ارائه خدمات سریع» است.
تیم امنیت معمولاً دنبال «کاهش ریسک، حفاظت، و کنترل قوی» است.
اگر CISO یا سرپرست امنیت زیرمجموعه IT باشد، معمولاً تصمیمات امنیتی تحت فشار نیازهای عملیاتی ضعیف میشود.
اگر امنیت مستقیماً زیر نظر CEO باشد، قدرت و استقلال دارد، اما اینجا ریسک تعامل ضعیف و اصطکاک با IT زیاد میشود.
و اما راهکار SecOps: اتحاد بجای جدایی کامل یا ادغام کامل
در SecOps به معنی حذف کامل مرز نیست، بلکه ایجاد یک فرهنگ و ساختار همکاری عمیق بین IT و امنیت است.
مدیریت چند-تخصصی: به جای اینکه مدیر امنیت و مدیر IT مستقیماً زیر نظر CEO یا CTO باشند، هر دو زیر نظر یک مدیر عملیاتی ارشد (مثلاً COO یا Chief Digital Officer) قرار میگیرند که مسئول «امنیت + کارایی + تحول دیجیتال» است.
تیمها عملاً جدا هستند، اما مجبور به همافزایی و پاسخگویی به یک هدف مشترک میشوند:
پروژهها، تغییرات، پیکربندیها و حتی رخدادها با مشارکت همزمان تخصص IT و امنیت پیش میرود.
تیمهای خرد (Squads) تشکیل میشود که هردو توان IT و Security را دارند (مثلاً یک Cloud Admin و یک Cloud Security Engineer در یک تیم محصول یا عملیات).
3. ویژگیهای این ساختار (به سبک SecOps):
همه فرآیندها (از طراحی تا عملیات) هم زمان هم امنیت و هم IT را پوشش میدهد.
گزارشدهی و پاسخگویی شفاف است: هم IT و هم Security به یک مدیر مشترک پاسخ میدهند که تعادل را برقرار میکند.
جلوگیری از فرافکنی: زمانی که رخداد یا اختلالی پیش میآید، مسیر حل مشکل ترکیب تخصصی دارد و همه مسئولند.
افزایش سرعت و امنیت: تیم پروژه از همان اول، هم رشد و هم ریسک را میبیند.
کاهش تعارضات و مقاومتها چون همه اهداف کلان سازمان (Agility + Security + Availability) همزمان دنبال میشود.
این SecOps پیشنهادش «زدودن مرز سفت و سخت» بین IT و امنیت نیست بلکه ایجاد یک هویت مشترک عملیاتی است که هر دو تیم، با مسئولیتپذیری مشترک، به یک مدیر ارشد (به جای CEO یا CTO صرفاً) متصل باشند و فرهنگ همکاری عمیق و روزانه داشته باشند. این ساختار هم استقلال نسبی به امنیت میدهد، هم IT را از سختگیریهای بیمنطق دور نگه میدارد، و هم به چابکی کسبوکار کمک میکند.
به نظرتون این ساختار ممکنه چه نکات و شاید اشکالاتی داشته باشه که لازم هست بررسی بشه؟
** ۷ سال پیش در یکی از بانکها CISO رو بردیم زیر نظر CEO ولی بعدش مشکلاتش رو دیدم . الان دارم واسه یه پتروشیمی این ساختار جدید رو پیاده میکنم.
#آکادمی_روزبه
مرکز تخصصی CISSP
شاید زمان تغییر نظر فرا رسیده
**روزبه نوروزی
Www.Roozbeh.academy
مشکل سنتی: درگیری و تعارض منافع مدیر امنیت و مدیر IT
مدیر IT (مثلاً CTO یا IT Manager) وظیفهاش «کارایی، دسترسپذیری و ارائه خدمات سریع» است.
تیم امنیت معمولاً دنبال «کاهش ریسک، حفاظت، و کنترل قوی» است.
اگر CISO یا سرپرست امنیت زیرمجموعه IT باشد، معمولاً تصمیمات امنیتی تحت فشار نیازهای عملیاتی ضعیف میشود.
اگر امنیت مستقیماً زیر نظر CEO باشد، قدرت و استقلال دارد، اما اینجا ریسک تعامل ضعیف و اصطکاک با IT زیاد میشود.
و اما راهکار SecOps: اتحاد بجای جدایی کامل یا ادغام کامل
در SecOps به معنی حذف کامل مرز نیست، بلکه ایجاد یک فرهنگ و ساختار همکاری عمیق بین IT و امنیت است.
مدیریت چند-تخصصی: به جای اینکه مدیر امنیت و مدیر IT مستقیماً زیر نظر CEO یا CTO باشند، هر دو زیر نظر یک مدیر عملیاتی ارشد (مثلاً COO یا Chief Digital Officer) قرار میگیرند که مسئول «امنیت + کارایی + تحول دیجیتال» است.
تیمها عملاً جدا هستند، اما مجبور به همافزایی و پاسخگویی به یک هدف مشترک میشوند:
پروژهها، تغییرات، پیکربندیها و حتی رخدادها با مشارکت همزمان تخصص IT و امنیت پیش میرود.
تیمهای خرد (Squads) تشکیل میشود که هردو توان IT و Security را دارند (مثلاً یک Cloud Admin و یک Cloud Security Engineer در یک تیم محصول یا عملیات).
3. ویژگیهای این ساختار (به سبک SecOps):
همه فرآیندها (از طراحی تا عملیات) هم زمان هم امنیت و هم IT را پوشش میدهد.
گزارشدهی و پاسخگویی شفاف است: هم IT و هم Security به یک مدیر مشترک پاسخ میدهند که تعادل را برقرار میکند.
جلوگیری از فرافکنی: زمانی که رخداد یا اختلالی پیش میآید، مسیر حل مشکل ترکیب تخصصی دارد و همه مسئولند.
افزایش سرعت و امنیت: تیم پروژه از همان اول، هم رشد و هم ریسک را میبیند.
کاهش تعارضات و مقاومتها چون همه اهداف کلان سازمان (Agility + Security + Availability) همزمان دنبال میشود.
این SecOps پیشنهادش «زدودن مرز سفت و سخت» بین IT و امنیت نیست بلکه ایجاد یک هویت مشترک عملیاتی است که هر دو تیم، با مسئولیتپذیری مشترک، به یک مدیر ارشد (به جای CEO یا CTO صرفاً) متصل باشند و فرهنگ همکاری عمیق و روزانه داشته باشند. این ساختار هم استقلال نسبی به امنیت میدهد، هم IT را از سختگیریهای بیمنطق دور نگه میدارد، و هم به چابکی کسبوکار کمک میکند.
به نظرتون این ساختار ممکنه چه نکات و شاید اشکالاتی داشته باشه که لازم هست بررسی بشه؟
** ۷ سال پیش در یکی از بانکها CISO رو بردیم زیر نظر CEO ولی بعدش مشکلاتش رو دیدم . الان دارم واسه یه پتروشیمی این ساختار جدید رو پیاده میکنم.
#آکادمی_روزبه
مرکز تخصصی CISSP
👍6🙏3
آسیب پذیری های فرآیند ها
چالشی قابل رفع با Red teaming
بخش اول: آسیبپذیریهای فرآیندی (Process Vulnerabilities) چیستند؟
آسیبپذیری فرآیندی، نقصی در یک رویه یا سیاست سازمانی است که میتواند توسط یک مهاجم برای به خطر انداختن امنیت، دسترسی به اطلاعات حساس، یا ایجاد اختلال در عملیات تجاری مورد سوءاستفاده قرار گیرد. این آسیبپذیریها معمولاً توسط اسکنرهای امنیتی خودکار قابل شناسایی نیستند، زیرا در منطق و عملکرد انسانی سازمان نهفتهاند.
مثالهای رایج از آسیبپذیریهای فرآیندی:
فرآیندهای ضعیف مدیریت هویت و دسترسی (Identity and Access Management - IAM):
عملیات Onboarding/Offboarding کارکنان: فرآیند اعطای دسترسی به کارمندان جدید ممکن است بیش از حد لازم باشد (اصل حداقل دسترسی یا Principle of Least Privilege نقض شود). خطرناکتر از آن، فرآیند لغو دسترسی کارمندی که سازمان را ترک کرده، ممکن است ناقص یا با تأخیر انجام شود و یک حساب کاربری فعال با دسترسیهای بالا باقی بماند.
تغییر نقش: وقتی کارمندی از یک بخش به بخش دیگر منتقل میشود، دسترسیهای قبلی او لغو نمیشود و به مرور زمان، فرد مجموعهای از دسترسیهای غیرضروری را انباشته میکند (Privilege Creep).
فرآیندهای ضعیف مدیریت تغییر (Change Management):
تغییرات اعمالشده بر روی سیستمهای حیاتی (مانند دیوار آتش یا سرورهای اصلی) بدون بررسی امنیتی کافی یا مستندسازی مناسب. یک مهاجم میتواند از یک تغییر ناامن برای نفوذ به شبکه بهرهبرداری کند.
نبود یا ضعف در فرآیندهای پاسخ به حوادث (Incident Response):
سازمان طرح مشخصی برای شناسایی، مهار و ریشهکن کردن یک حمله سایبری ندارد. در نتیجه، هنگام وقوع یک حادثه واقعی، سردرگمی، تأخیر و تصمیمات نادرست منجر به افزایش خسارت میشود.
ضعف در آگاهیرسانی امنیتی و آموزش کارکنان:
کارمندان در مورد حملات فیشینگ، مهندسی اجتماعی یا نحوه مدیریت دادههای حساس به درستی آموزش ندیدهاند. این آسیبپذیری انسانی، دروازه اصلی بسیاری از حملات موفق است.
سیاستهای ضعیف مدیریت رمز عبور:
اجبار نکردن استفاده از رمزهای عبور پیچیده، عدم وجود سیاست انقضای رمز عبور، یا اجازه استفاده مجدد از رمزهای قدیمی.
فرآیندهای فیزیکی ناامن:
عدم وجود کنترل دسترسی مناسب به اتاق سرور، اجازه ورود افراد ناشناس به ساختمان بدون احراز هویت، یا روشهای ناامن برای از بین بردن اسناد فیزیکی حاوی اطلاعات حساس.
بخش دوم: تیم قرمز (Red Teaming)؛ شبیهساز حملات واقعی
تیم قرمز یک گروه متخصص امنیت است که وظیفه آن، به چالش کشیدن امنیت یک سازمان از طریق شبیهسازی حملات یک مهاجم واقعی، با انگیزه و با منابع کافی است. هدف اصلی تیم قرمز، صرفاً پیدا کردن یک لیست از آسیبپذیریها نیست (مانند کاری که در تست نفوذ سنتی انجام میشود)، بلکه ارزیابی جامع تواناییهای دفاعی سازمان (شامل افراد، فرآیندها و تکنولوژی) در برابر یک تهدید واقعی و مستمر است.
ویژگیهای کلیدی یک عملیات تیم قرمز:
هدفمحور (Objective-Driven): عملیات با یک هدف مشخص شروع میشود، مانند “دسترسی به پایگاه داده مشتریان” یا “ایجاد اختلال در خط تولید”.
شبیهسازی تهدید (Threat Emulation): تیم قرمز از تاکتیکها، تکنیکها و رویههای (TTPs) گروههای مهاجم واقعی (APTها) استفاده میکند.
چندوجهی (Multi-faceted): حمله تنها به یک لایه محدود نمیشود و میتواند شامل جنبههای فنی (هک شبکه)، فیزیکی (ورود به ساختمان) و انسانی (مهندسی اجتماعی) باشد.
مخفیانه (Stealthy): تیم قرمز تلاش میکند تا حد امکان توسط تیم دفاعی سازمان (تیم آبی یا Blue Team) شناسایی نشود تا بتواند تواناییهای شناسایی و پاسخ آنها را به طور واقعی ارزیابی کند.
تمرکز بر زنجیره حمله (Kill Chain): تیم قرمز کل مراحل یک حمله را از شناسایی اولیه تا رسیدن به هدف نهایی شبیهسازی میکند.
بخش سوم: همافزایی تیم قرمز و کشف آسیبپذیریهای فرآیندی
ارتباط بین تیم قرمز و آسیبپذیریهای فرآیندی در اینجا مشخص میشود: تیم قرمز بهترین ابزار برای کشف و اثبات وجود آسیبپذیریهای فرآیندی است.
یک اسکنر نمیتواند تشخیص دهد که فرآیند Offboarding شما ضعیف است، اما تیم قرمز میتواند:
شناسایی: تیم قرمز لیستی از کارمندان سابق را از منابع عمومی مانند LinkedIn پیدا میکند.
آزمون: سعی میکند با استفاده از اطلاعات کاربری آنها (مثلاً firstname.lastname@company.com) به سیستمهای خارجی مانند VPN یا ایمیل متصل شود.
ادامه در پست بعد ....
#آکادمی_روزبه
مرکز تخصصی CISSP
چالشی قابل رفع با Red teaming
بخش اول: آسیبپذیریهای فرآیندی (Process Vulnerabilities) چیستند؟
آسیبپذیری فرآیندی، نقصی در یک رویه یا سیاست سازمانی است که میتواند توسط یک مهاجم برای به خطر انداختن امنیت، دسترسی به اطلاعات حساس، یا ایجاد اختلال در عملیات تجاری مورد سوءاستفاده قرار گیرد. این آسیبپذیریها معمولاً توسط اسکنرهای امنیتی خودکار قابل شناسایی نیستند، زیرا در منطق و عملکرد انسانی سازمان نهفتهاند.
مثالهای رایج از آسیبپذیریهای فرآیندی:
فرآیندهای ضعیف مدیریت هویت و دسترسی (Identity and Access Management - IAM):
عملیات Onboarding/Offboarding کارکنان: فرآیند اعطای دسترسی به کارمندان جدید ممکن است بیش از حد لازم باشد (اصل حداقل دسترسی یا Principle of Least Privilege نقض شود). خطرناکتر از آن، فرآیند لغو دسترسی کارمندی که سازمان را ترک کرده، ممکن است ناقص یا با تأخیر انجام شود و یک حساب کاربری فعال با دسترسیهای بالا باقی بماند.
تغییر نقش: وقتی کارمندی از یک بخش به بخش دیگر منتقل میشود، دسترسیهای قبلی او لغو نمیشود و به مرور زمان، فرد مجموعهای از دسترسیهای غیرضروری را انباشته میکند (Privilege Creep).
فرآیندهای ضعیف مدیریت تغییر (Change Management):
تغییرات اعمالشده بر روی سیستمهای حیاتی (مانند دیوار آتش یا سرورهای اصلی) بدون بررسی امنیتی کافی یا مستندسازی مناسب. یک مهاجم میتواند از یک تغییر ناامن برای نفوذ به شبکه بهرهبرداری کند.
نبود یا ضعف در فرآیندهای پاسخ به حوادث (Incident Response):
سازمان طرح مشخصی برای شناسایی، مهار و ریشهکن کردن یک حمله سایبری ندارد. در نتیجه، هنگام وقوع یک حادثه واقعی، سردرگمی، تأخیر و تصمیمات نادرست منجر به افزایش خسارت میشود.
ضعف در آگاهیرسانی امنیتی و آموزش کارکنان:
کارمندان در مورد حملات فیشینگ، مهندسی اجتماعی یا نحوه مدیریت دادههای حساس به درستی آموزش ندیدهاند. این آسیبپذیری انسانی، دروازه اصلی بسیاری از حملات موفق است.
سیاستهای ضعیف مدیریت رمز عبور:
اجبار نکردن استفاده از رمزهای عبور پیچیده، عدم وجود سیاست انقضای رمز عبور، یا اجازه استفاده مجدد از رمزهای قدیمی.
فرآیندهای فیزیکی ناامن:
عدم وجود کنترل دسترسی مناسب به اتاق سرور، اجازه ورود افراد ناشناس به ساختمان بدون احراز هویت، یا روشهای ناامن برای از بین بردن اسناد فیزیکی حاوی اطلاعات حساس.
بخش دوم: تیم قرمز (Red Teaming)؛ شبیهساز حملات واقعی
تیم قرمز یک گروه متخصص امنیت است که وظیفه آن، به چالش کشیدن امنیت یک سازمان از طریق شبیهسازی حملات یک مهاجم واقعی، با انگیزه و با منابع کافی است. هدف اصلی تیم قرمز، صرفاً پیدا کردن یک لیست از آسیبپذیریها نیست (مانند کاری که در تست نفوذ سنتی انجام میشود)، بلکه ارزیابی جامع تواناییهای دفاعی سازمان (شامل افراد، فرآیندها و تکنولوژی) در برابر یک تهدید واقعی و مستمر است.
ویژگیهای کلیدی یک عملیات تیم قرمز:
هدفمحور (Objective-Driven): عملیات با یک هدف مشخص شروع میشود، مانند “دسترسی به پایگاه داده مشتریان” یا “ایجاد اختلال در خط تولید”.
شبیهسازی تهدید (Threat Emulation): تیم قرمز از تاکتیکها، تکنیکها و رویههای (TTPs) گروههای مهاجم واقعی (APTها) استفاده میکند.
چندوجهی (Multi-faceted): حمله تنها به یک لایه محدود نمیشود و میتواند شامل جنبههای فنی (هک شبکه)، فیزیکی (ورود به ساختمان) و انسانی (مهندسی اجتماعی) باشد.
مخفیانه (Stealthy): تیم قرمز تلاش میکند تا حد امکان توسط تیم دفاعی سازمان (تیم آبی یا Blue Team) شناسایی نشود تا بتواند تواناییهای شناسایی و پاسخ آنها را به طور واقعی ارزیابی کند.
تمرکز بر زنجیره حمله (Kill Chain): تیم قرمز کل مراحل یک حمله را از شناسایی اولیه تا رسیدن به هدف نهایی شبیهسازی میکند.
بخش سوم: همافزایی تیم قرمز و کشف آسیبپذیریهای فرآیندی
ارتباط بین تیم قرمز و آسیبپذیریهای فرآیندی در اینجا مشخص میشود: تیم قرمز بهترین ابزار برای کشف و اثبات وجود آسیبپذیریهای فرآیندی است.
یک اسکنر نمیتواند تشخیص دهد که فرآیند Offboarding شما ضعیف است، اما تیم قرمز میتواند:
شناسایی: تیم قرمز لیستی از کارمندان سابق را از منابع عمومی مانند LinkedIn پیدا میکند.
آزمون: سعی میکند با استفاده از اطلاعات کاربری آنها (مثلاً firstname.lastname@company.com) به سیستمهای خارجی مانند VPN یا ایمیل متصل شود.
ادامه در پست بعد ....
#آکادمی_روزبه
مرکز تخصصی CISSP
❤9
👆👆قسمت دوم از پست قبل
بهرهبرداری: در صورت موفقیت، تیم قرمز از این حساب کاربری “زامبی” برای نفوذ اولیه به شبکه استفاده میکند و به این ترتیب، ضعف در فرآیند Offboarding را نه به صورت تئوری، بلکه به صورت عملی اثبات میکند.
چگونه تیم قرمز آسیبپذیریهای فرآیندی را آشکار میکند؟
مهندسی اجتماعی: یک عضو تیم قرمز با واحد پشتیبانی فنی (Help Desk) تماس میگیرد و با جعل هویت یک مدیر ارشد، درخواست بازنشانی رمز عبور میکند. اگر پشتیبانی فنی بدون احراز هویت دقیق این کار را انجام دهد، یک آسیبپذیری فرآیندی بزرگ در “فرآیند احراز هویت و پشتیبانی” آشکار شده است. این سناریو یک ضعف تکنولوژیک نیست، بلکه یک ضعف رویهای است.
تست نفوذ فیزیکی: عضوی از تیم قرمز با پوشیدن لباس مبدل (مثلاً لباس پیک یا تکنسین) تلاش میکند وارد ساختمان شرکت شود. اگر نگهبانان یا کارمندان به او اجازه ورود بدهند بدون اینکه هویت او را بررسی کنند یا با کسی هماهنگ کنند، این نشاندهنده ضعف در “فرآیندهای امنیت فیزیکی و کنترل دسترسی” است.
حرکت جانبی در شبکه (Lateral Movement): پس از نفوذ اولیه، تیم قرمز تلاش میکند در شبکه حرکت کند. اگر بتواند به سادگی از یک سیستم کماهمیت به یک سرور حیاتی دسترسی پیدا کند، این ممکن است نشاندهنده ضعف در “فرآیند بخشبندی شبکه (Network Segmentation)” و “سیاستهای دیوار آتش داخلی” باشد.
خروجی یک عملیات تیم قرمز موفق:
خروجی نهایی، گزارشی است که نه تنها آسیبپذیریهای فنی، بلکه یک جدول زمانی دقیق از اقدامات تیم قرمز، واکنش (یا عدم واکنش) تیم آبی و لیستی از آسیبپذیریهای فرآیندی کشفشده را ارائه میدهد. این گزارش به مدیران ارشد کمک میکند تا بفهمند چگونه یک مهاجم توانست با دور زدن سیاستها و رویهها، به اهداف خود دست یابد.
نتیجهگیری
امنیت سایبری مدرن، یک مبارزه چندلایه است که صرفاً با خرید جدیدترین ابزارهای تکنولوژیک به پیروزی نمیرسد. آسیبپذیریهای فرآیندی، شکافهای خاموش و خطرناکی در زره دفاعی یک سازمان هستند که اغلب از چشم ابزارهای خودکار پنهان میمانند.
تیم قرمز با رویکرد واقعگرایانه و خصمانه خود، به مثابه یک “آینه حقیقت” عمل میکند. این تیم نه تنها حفرههای موجود در تکنولوژی، بلکه ضعفهای ریشهدار در سیاستها، رویهها و فرهنگ امنیتی سازمان را آشکار میسازد. سرمایهگذاری بر روی عملیات تیم قرمز، یک گام حیاتی برای سازمانهایی است که میخواهند از یک رویکرد امنیتی واکنشی (Reactive) به یک رویکرد پیشگیرانه و هوشمند (Proactive) حرکت کرده و در برابر تهدیدات پیچیده امروزی، تابآوری واقعی کسب کنند. در نهایت، قویترین دیوار آتشها و پیچیدهترین سیستمهای تشخیص نفوذ در برابر کارمندی که فریب یک ایمیل فیشینگ را میخورد یا فرآیندی که اجازه دسترسی بیش از حد میدهد، بیدفاع هستند.
#آکادمی_روزبه
مرکز تخصصی CISSP
بهرهبرداری: در صورت موفقیت، تیم قرمز از این حساب کاربری “زامبی” برای نفوذ اولیه به شبکه استفاده میکند و به این ترتیب، ضعف در فرآیند Offboarding را نه به صورت تئوری، بلکه به صورت عملی اثبات میکند.
چگونه تیم قرمز آسیبپذیریهای فرآیندی را آشکار میکند؟
مهندسی اجتماعی: یک عضو تیم قرمز با واحد پشتیبانی فنی (Help Desk) تماس میگیرد و با جعل هویت یک مدیر ارشد، درخواست بازنشانی رمز عبور میکند. اگر پشتیبانی فنی بدون احراز هویت دقیق این کار را انجام دهد، یک آسیبپذیری فرآیندی بزرگ در “فرآیند احراز هویت و پشتیبانی” آشکار شده است. این سناریو یک ضعف تکنولوژیک نیست، بلکه یک ضعف رویهای است.
تست نفوذ فیزیکی: عضوی از تیم قرمز با پوشیدن لباس مبدل (مثلاً لباس پیک یا تکنسین) تلاش میکند وارد ساختمان شرکت شود. اگر نگهبانان یا کارمندان به او اجازه ورود بدهند بدون اینکه هویت او را بررسی کنند یا با کسی هماهنگ کنند، این نشاندهنده ضعف در “فرآیندهای امنیت فیزیکی و کنترل دسترسی” است.
حرکت جانبی در شبکه (Lateral Movement): پس از نفوذ اولیه، تیم قرمز تلاش میکند در شبکه حرکت کند. اگر بتواند به سادگی از یک سیستم کماهمیت به یک سرور حیاتی دسترسی پیدا کند، این ممکن است نشاندهنده ضعف در “فرآیند بخشبندی شبکه (Network Segmentation)” و “سیاستهای دیوار آتش داخلی” باشد.
خروجی یک عملیات تیم قرمز موفق:
خروجی نهایی، گزارشی است که نه تنها آسیبپذیریهای فنی، بلکه یک جدول زمانی دقیق از اقدامات تیم قرمز، واکنش (یا عدم واکنش) تیم آبی و لیستی از آسیبپذیریهای فرآیندی کشفشده را ارائه میدهد. این گزارش به مدیران ارشد کمک میکند تا بفهمند چگونه یک مهاجم توانست با دور زدن سیاستها و رویهها، به اهداف خود دست یابد.
نتیجهگیری
امنیت سایبری مدرن، یک مبارزه چندلایه است که صرفاً با خرید جدیدترین ابزارهای تکنولوژیک به پیروزی نمیرسد. آسیبپذیریهای فرآیندی، شکافهای خاموش و خطرناکی در زره دفاعی یک سازمان هستند که اغلب از چشم ابزارهای خودکار پنهان میمانند.
تیم قرمز با رویکرد واقعگرایانه و خصمانه خود، به مثابه یک “آینه حقیقت” عمل میکند. این تیم نه تنها حفرههای موجود در تکنولوژی، بلکه ضعفهای ریشهدار در سیاستها، رویهها و فرهنگ امنیتی سازمان را آشکار میسازد. سرمایهگذاری بر روی عملیات تیم قرمز، یک گام حیاتی برای سازمانهایی است که میخواهند از یک رویکرد امنیتی واکنشی (Reactive) به یک رویکرد پیشگیرانه و هوشمند (Proactive) حرکت کرده و در برابر تهدیدات پیچیده امروزی، تابآوری واقعی کسب کنند. در نهایت، قویترین دیوار آتشها و پیچیدهترین سیستمهای تشخیص نفوذ در برابر کارمندی که فریب یک ایمیل فیشینگ را میخورد یا فرآیندی که اجازه دسترسی بیش از حد میدهد، بیدفاع هستند.
#آکادمی_روزبه
مرکز تخصصی CISSP
❤7
🔴مهم و جدید: وقتی EDRو XDR شما دور میخورد
جایی کهSOC شما باید وارد عمل شود
در بسیاری از سازمانها، ابزارهای EDR و SIEM معمولاً دستورات خط فرمان مرتبط با Volume Shadow Copy (VSS) را برای جلوگیری از استخراج غیرمجاز دادهها مانیتور میکنند؛ اما روشی وجود دارد که میتواند این مکانیزمهای دفاعی را دور بزند. با استفاده از قابلیت Previous Versions در Windows Explorer، مهاجم میتواند بدون اجرای هیچ دستور خط فرمان یا ابزار خاص، مستقیماً به Snapshotهای قبلی فایلها یا پوشهها دسترسی پیدا کند. کافی است مسیر UNC شبیه به
\\localhost\C$\@GMT-تاریخخاص\Windows\NTDS\ntds.dit
را در Windows Explorer وارد کند تا بتواند فایل حساس مثل ntds.dit یک Domain Controller را از داخل یک Snapshot استخراج کند.
این روش عموماً در هیچ راهکار مانیتورینگ مبتنی بر فرمانهای VSS قابل شناسایی نیست، چراکه هیچ رخداد یا لاگ خاصی از اجرای دستور ثبت نمیشود؛ به همین دلیل، این یک گپ امنیتی مهم است که اغلب توسط تیمهای Blue Team و SOC نادیده گرفته میشود.
برای کاهش این ریسک باید دسترسی به مسیرهای دارای نشانه@GMT- در فایل سرورها و سرورهای دامین مانیتور شود و همچنین تیم تحلیلگر به این تکنیکها آگاه گردد تا اقدامات متقابل مناسب طراحی و پیادهسازی گردد.
#آکادمی_روزبه
مرکز تخصصی CISSP
جایی کهSOC شما باید وارد عمل شود
در بسیاری از سازمانها، ابزارهای EDR و SIEM معمولاً دستورات خط فرمان مرتبط با Volume Shadow Copy (VSS) را برای جلوگیری از استخراج غیرمجاز دادهها مانیتور میکنند؛ اما روشی وجود دارد که میتواند این مکانیزمهای دفاعی را دور بزند. با استفاده از قابلیت Previous Versions در Windows Explorer، مهاجم میتواند بدون اجرای هیچ دستور خط فرمان یا ابزار خاص، مستقیماً به Snapshotهای قبلی فایلها یا پوشهها دسترسی پیدا کند. کافی است مسیر UNC شبیه به
\\localhost\C$\@GMT-تاریخخاص\Windows\NTDS\ntds.dit
را در Windows Explorer وارد کند تا بتواند فایل حساس مثل ntds.dit یک Domain Controller را از داخل یک Snapshot استخراج کند.
این روش عموماً در هیچ راهکار مانیتورینگ مبتنی بر فرمانهای VSS قابل شناسایی نیست، چراکه هیچ رخداد یا لاگ خاصی از اجرای دستور ثبت نمیشود؛ به همین دلیل، این یک گپ امنیتی مهم است که اغلب توسط تیمهای Blue Team و SOC نادیده گرفته میشود.
برای کاهش این ریسک باید دسترسی به مسیرهای دارای نشانه@GMT- در فایل سرورها و سرورهای دامین مانیتور شود و همچنین تیم تحلیلگر به این تکنیکها آگاه گردد تا اقدامات متقابل مناسب طراحی و پیادهسازی گردد.
#آکادمی_روزبه
مرکز تخصصی CISSP
❤8💯4👍3
حمله ADCS در اکتیو دایرکتوری
بسطی بر این نوع حملات پس از ۴ سال از ابداع
در حملات ADCS، مهاجم به واسطه ضعفهای پیکربندی در سرویس صدور گواهینامه (مثل اعطای بیش از حد دسترسی به Enroll یا گزینه ENROLLEE_SUPPLIES_SUBJECT) میتواند گواهینامه معتبری اخذ کند که اعتبار Kerberos TGT یا حساب با امتیاز بالا (مثلاً Domain Admin) را شبیهسازی میکند؛ این یعنی مهاجم با استفاده از ابزارهایی همچون Certify، بدون نیاز به استخراج یا هشکردن پسورد، هویت معتبر در کل دامنه به دست میآورد. این گواهینامهها عمدتاً کاملاً قانونی به نظر میرسند، چون در بستر رسمی AD صادر میشوند و اِکسپلویت آن معمولاً هیچ ردپایی از حملات کلاسیک چون mimikatz (dump LSASS) یا Golden Ticket در مموری باقی نمیگذارد.
در نتیجه تشخیص چنین حملاتی بسیار دشوارتر است، چون لاگهای صدور گواهینامه و عملکردهای PKI به سادگی و توسط بسیاری از SIEMها جمعآوری و تحلیل نمیشود. این حمله کاملاً زیر رادار بسیاری از مکانیزمهای مانیتورینگ قرار میگیرد، بر خلاف حملات Pass-the-Hash، Pass-the-Ticket یا حتی DCSync که عمدتاً ردپای قابل شناسایی در لاگهای AD و Event Log دارند.
https://dfir.ch/posts/tear_down_castle_part_one/#1-adcs-active-directory-certificate-services
#آکادمی_روزبه
مرکز تخصصی CISSP
بسطی بر این نوع حملات پس از ۴ سال از ابداع
در حملات ADCS، مهاجم به واسطه ضعفهای پیکربندی در سرویس صدور گواهینامه (مثل اعطای بیش از حد دسترسی به Enroll یا گزینه ENROLLEE_SUPPLIES_SUBJECT) میتواند گواهینامه معتبری اخذ کند که اعتبار Kerberos TGT یا حساب با امتیاز بالا (مثلاً Domain Admin) را شبیهسازی میکند؛ این یعنی مهاجم با استفاده از ابزارهایی همچون Certify، بدون نیاز به استخراج یا هشکردن پسورد، هویت معتبر در کل دامنه به دست میآورد. این گواهینامهها عمدتاً کاملاً قانونی به نظر میرسند، چون در بستر رسمی AD صادر میشوند و اِکسپلویت آن معمولاً هیچ ردپایی از حملات کلاسیک چون mimikatz (dump LSASS) یا Golden Ticket در مموری باقی نمیگذارد.
در نتیجه تشخیص چنین حملاتی بسیار دشوارتر است، چون لاگهای صدور گواهینامه و عملکردهای PKI به سادگی و توسط بسیاری از SIEMها جمعآوری و تحلیل نمیشود. این حمله کاملاً زیر رادار بسیاری از مکانیزمهای مانیتورینگ قرار میگیرد، بر خلاف حملات Pass-the-Hash، Pass-the-Ticket یا حتی DCSync که عمدتاً ردپای قابل شناسایی در لاگهای AD و Event Log دارند.
https://dfir.ch/posts/tear_down_castle_part_one/#1-adcs-active-directory-certificate-services
#آکادمی_روزبه
مرکز تخصصی CISSP
❤6👍5