Skip to content

ONHEXGROUP

اخبار دنیای امنیت سایبری

  • اخبار
    • آسیب پذیری امنیتی
    • آنالیز بدافزار
    • کنفرانس ،دوره ، وبینار ، لایو ، CTF
    • بازیگران تهدید
    • توسعه اکسپلویت
    • افشای اطلاعات
    • باگ بانتی
    • تیم آبی
    • تیم قرمز
    • امنیت وب
  • دوره های آموزشی
    • دوره رایگان مهندسی معکوس نرم افزار
  • لیست های ویژه
    • موتورهای جستجو برای امنیت سایبری
    • کاتالوگ KEV آژانس CISA
    • آسیب پذیری های وردپرس
      • آسیب پذیری پلاگین ها
      • آسیب پذیری های هسته
      • آسیب پذیری تم ها
    • محصولات خارج از پشتیبانی مایکروسافت
      • محصولات مایکروسافتی که در سال 2022 پشتیبانی نمیشن
      • محصولات مایکروسافتی که در سال 2023 پشتیبانی نمیشن
      • لیست محصولات مایکروسافتی که در سال 2024 پشتیبانی نمیشن
      • لیست محصولات مایکروسافتی که در سال 2025 پشتیبانی نمیشن
    • معرفی فیلم ها و سریالهای مرتبط با هک و امنیت
  • آموزش های ویدیویی
  • انتشارات
    • مجله
    • مقالات
    • پادکست
  • پروژه ها
    • ماشین آسیب پذیر
      • وردپرس آسیب پذیر
  • حمایت مالی ( Donate)
  • تماس با ما
 
  • Home
  • اخبار
  • پیشنهادات گوگل برای مدیریت آسیب پذیری ها
  • آسیب پذیری امنیتی
  • اخبار
  • بازیگران تهدید
  • باگ بانتی

پیشنهادات گوگل برای مدیریت آسیب پذیری ها

On فروردین 28, 1402تیر 25, 1403
seyyid
Share
زمان مطالعه: 7 دقیقه

گوگل یه مقاله ای منتشر کرده در خصوص اینکه اکوسیستم امنیت در خصوص آسیب پذیری ها چه مشکلاتی داره و یسری پیشنهاد در این خصوص داده و یسری کار هم انجام داده.

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

عموما بحثها روی آسیب پذیری های زیرودی و تهدیدات امنیتی هستش و تمرکز روی عواملی که منجر به این آسیب پذیری ها میشه، کمتر هستش. Project Zero ما که ،روی آسیب پذیری های سخت افزاری و نرم افزاری کار میکنه ، تمرکز اصلیش روی سخت تر کردن زیرودی ها هستش اما نیاز به ایجاد رویکردهای جدیدی داریم تا اکسپلویت کردن رو سخت تر کنه. انجام این کار نیاز به همکاری تمام ذینفعان داره :

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

وقتی به اکوسیستم نگاه میکنیم ، میبینیم که هنوز کارهای مهمی برای همکاری ذینغعان وجود داره. ما چهار زمینه رو برای بهبود پیشنهاد میدیم:

  • رویکردی فراتر از زیرودی
  • عادی سازی شفافیت
  • حمایت از محققان
  • فرار از حلقه تکرار

به این موارد فقط اشاره نمیکنیم بلکه این پشنهادات رو عملی هم کردیم. برای همین یسری ابتکارات برای ایجاد این موارد داریم:

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

 

 

رویکردی فراتر از زیردی :

عمر یه آسیب پذیری با انتشار اصلاحیه تموم نمیشه. سالهاست که صنعت و سیاست گذاران روی زیرودی ها تمرکز دارن و اونا رو منبع اصلی ناامنی میدونن. ما باید رویکرد جامعتری به مدیریت آسیب پذیری ها با تمرکز به اعمال اصلاحیه و مدیریت چرخه عمر نرم افزار داشته باشیم.

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

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

  • تعداد دفعاتی که وصله ارائه میشه
  • ارائه انگیزه و اختیارات برای اعمال اتوماتیک وصله ها
  • آیا اصلاحات امنیتی بصورت مجزا ارائه میشن. ( منظور جدا بودن بروزرسانی ویژگی های برنامه و بروزرسانی های امنیتی برنامه) یا اینکه میشه بروزرسانی های برنامه رو از بروزرسانی کامل سیستم در دستگاههای همراه جدا کرد یا نه

ایجاد سهولت اعمال وصله ها در سازمانها یه مورد مطالعاتی ویژه هستش. با توجه به اینکه اغلب کمپین ها از آسیب پذیری های شناخته شده و وصله نشده استفاده میکنن ، سازمانها به دلیل عدم اعمال بموقع وصله ها نقض میشن. صنعت باید روی سهولت تست و اعمال وصله ها برای مشتریاش سرمایه گذاری کنه. تجزیه و تحلیل بیشتر از روند اعمال وصله ها میتونه کمک کننده باشه. مثلا نمونه ای که ما برای وصله های Google Kubernetes Engine منتشر کردیم.

در خصوص مدیریت چرخه عمر نرم افزار، گوگل معتقده که محصولات باید با خط مشی هایی درباره طول عمر مورد انتظار ( تاریخ انقضاء) و مدلهای پشتیبانی و اطلاع رسانی برای مشتریان پایین دستی ارائه بشن. مثلا تیم اندروید یه جدول زمانی برای شرکای پایین دستی مثله OEMها ارائه میده و مشخص میکنه که این نسخه تا چه زمانی وصله های گوگل دریافت میکنه . در این خصوص حداقل 3.5 سال پشتیبانی تضمین شده ارائه میشه.

 

عادی سازی شفافیت :

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

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

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

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

در حالت ایده آل ، دولتها هم در این شفافیت نقش دارن،  چون ملاحظات تدافعی و تهاجمی رو متعادل میکنه. فرایند Vulnerability Equities Process آمریکا و اصول انتشار مسولانه دولت استرالیا یه گام مثبت در این خصوصه ، اما انتشار داده های بیشتر میتونه به ماموریت اونا در آینده بیشتر کمک کنه.

کشورهای دیگه هم باید از این اصول پیروی کنن و اونو بهبود بدن از جمله اینکه میتونن میزان آسیب پذیری های افشاء شده و آسیب پذیری هایی که از افشاشون منع شدن رو به اشتراک بزارن یا اشتراک اکسپلویتهای بصورت کلی .

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

 

حمایت از محققین:

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

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

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

 

فرار از حلقه تکرار و ناامیدی:

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

در گوگل ما تلاش میکنیم تا کلا کلاس تهدیدات و آسیب پذیری ها رو حذف کنیم. این امر با بررسی ریشه ای آسیب پذیری ها امکانپذیره که از طریق  بررسی مسائل معماری زیربنایی که باعث ایجاد این آسیب پذیری ها میشه ،محقق میشه.  اغلب فروشندگان اصلاحیه های ناقصی رو برای آسیب پذیری ها منتشر میکنن و باگ رو بدون اصلاح علت اصلی اون اصلاح میکنن. این منجر به دور زدن وصله و اجرای مجدد اکسپلویت میشه. برای مثال 17 مورد از 40 مورد (42.5 درصد) زیرودی که در سال 2022 اکسپلویتشون در حملاتی مورد استفاده قرار گرفته بود ، از باگهای شناخته شده قبلی بودن. این مسئله به دلایل زیر ایجاد میشه:

  • ناتوانی در درک علت اصلی آسیب پذیری
  • عدم اولویت بندی برای رفع واقعی اون

تمرکز روی رفع علت اصلی آسیب پذیری ، باعث میشه دولت و صنعت و کاربر این چرخه تکرار رو بشکنه. سیاستگذارن و صنعت میتونن در مواردی به جای رسیدگی به تهدیدات و آسیب پذیری ها در زمان بروزشون، به ایمن بودن محصول توجه کنن. تلاشهای مرکز ملی امنیت سایبری بریتانیا ، NIST و CISA برای تعریف و اشتراک بهترین شیوه های امنیتی در تمام طول چرخه عمر توسعه نرم افزار ، قدم خوبیه اما این تلاشها باید در راستای حل علت ریشه ای باشه. مثلا یه توسعه دهنده میتونه از طریق راهنمای توسعه امن NIST بدون استفاده از یه زبان برنامه نویسی مدرن و ایمن در برابر آسیب پذیری های حافظه ، برنامه اش توسعه بده. یا یه مثال دیگه Software Bill of Materials (SBoM) شروع خوبی برای درک وابستگی های سیستمی و اجزای ناامنه اما SBoMها به خودی خود امنیت رو بهبود نمیدن. SBoMها باید خروجی سیستم‌های ساخت نرم‌افزار ایمن‌ و ارزیابی شده باشن  و باید چارچوب‌هایی برای تجزیه و تحلیل SBoM‌ها در مقیاس مناسب ایجاد بشه.

برای توسعه رویکردهای انعطاف پذیر که منجر به توسعه نرم افزارهای ایمن برای سازمانها با هر اندازه و سطح بین اللملی باشه، نیاز به مشارکت بخش دولتی و خصوصی هستش. در گوگل بطور مداوم دستورالعملها رو برای توسعه دهندگان بروزرسانی میکنیم، مثلا اهمیت به اصول ایمنی در چرخه کامل توسعه نرم افزار ، استفاده از RUST برای توسعه در دستگاههای جدید ، تا به تکنیکهای در حال رشد مهاجمین جوابگو باشن .

 

منبع

 

 

اشتراک در شبکه های اجتماعی :

Facebook
Twitter
Pinterest
LinkedIn
In آسیب پذیری امنیتی اخبار بازیگران تهدید باگ بانتیIn hackingpolicycouncil , srldf , گوگل

راهبری نوشته

5000 حمله سایبری به روسیه توسط ناتو
آسیب پذیری بحرانی در محصولات Hikvision

دیدگاهتان را بنویسید لغو پاسخ

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *

دسته‌ها

  • Osint
  • آسیب پذیری امنیتی
  • آموزش های ویدیویی
  • آنالیز بدافزار
  • اخبار
  • افشای اطلاعات
  • امنیت وب
  • انتشارات
  • اینترنت اشیاء
  • بازیگران تهدید
  • باگ بانتی
  • پادکست
  • پروژه ها
  • توسعه اکسپلویت
  • تیم آبی
  • تیم قرمز
  • دوره های آموزشی
  • فازینگ
  • کنفرانس ،دوره ، وبینار ، لایو ، CTF
  • لیست های ویژه
  • ماشین آسیب پذیر
  • مجله
  • مقالات
  • مهندسی معکوس نرم افزار

بایگانی‌ها

  • می 2025
  • آوریل 2025
  • مارس 2025
  • فوریه 2025
  • ژانویه 2025
  • دسامبر 2024
  • نوامبر 2024
  • اکتبر 2024
  • سپتامبر 2024
  • آگوست 2024
  • جولای 2024
  • ژوئن 2024
  • می 2024
  • آوریل 2024
  • مارس 2024
  • فوریه 2024
  • ژانویه 2024
  • دسامبر 2023
  • نوامبر 2023
  • اکتبر 2023
  • سپتامبر 2023
  • آگوست 2023
  • جولای 2023
  • ژوئن 2023
  • می 2023
  • آوریل 2023
  • مارس 2023
  • فوریه 2023
  • ژانویه 2023
  • دسامبر 2022

پست های مرتبط

  • اخبار
  • امنیت وب
  • بازیگران تهدید
seyyid
On اردیبهشت 9, 1402اردیبهشت 10, 1402

دستگیری یه فروشنده داده در اوکراین

  • آسیب پذیری امنیتی
  • اخبار
  • اینترنت اشیاء
seyyid
On مرداد 16, 1402مرداد 17, 1402

کشف بکدور در تجهیزات رادیویی، پلیسی و نظامی

  • آنالیز بدافزار
  • اخبار
  • بازیگران تهدید
seyyid
On اسفند 20, 1401فروردین 28, 1402

محصول SonicWall SMA هدف بدافزاری یه گروه احتمالا چینی

  • آسیب پذیری امنیتی
  • اخبار
  • توسعه اکسپلویت
  • تیم آبی
  • تیم قرمز
  • مقالات
seyyid
On مرداد 7, 1402مرداد 8, 1402

بررسی هفتگی آسیب پذیری های منتشر شده در ZDI – (31 تیر تا 6 مرداد)

درباره ما

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

تگ ها

0day APT command injection Deserialization of Untrusted Data Directory Traversal FBI Fortinet Heap buffer overflow integer overflow kali LockBit Memory Corruption nuclei Off By One Security out-of-bounds write Out of bounds read Patch Tuesday PWN2OWN Stack Buffer overflow type confusion use after free vulnerable wordpress XSS ZDI vulnerability آموزش اکسپلویت نویسی ارز دیجیتال اندروید اپل اکسپلویت باج افزار تلگرام زیرودی سیسکو فارنزیک فورتی نت فیشینگ لاک بیت مایکروسافت هوش مصنوعی وردپرس وردپرس آسیب پذیر ویندوز پلاگین کروم گوگل

شبکه های اجتماعی

    • Instagram
    • Telegram
    • Twitter
    • GitHub
    • YouTube
    • LinkedIn
      کپی مطالب با ذکر منبع بلامانع است | 1401-1404