This is beta version of Ravro English website. Some dynamic texts are in Persian. If you need support, contact with support@ravro.ir.
گفتنی‌هایی راجع به فرمول ارزش‌گذاری آسیب پذیری ها در راورو

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

1352

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

باگ بانتی راورو

داخل پرانتز: این گفت‌وگو در تاریخ ۲۲ دی ماه ۱۴۰۰ انجام شده است.

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

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

_ بذار بی‌مقدمه بریم سراغ اصل مطلب و از "چرایی" شروع کنیم: چرا برای محاسبه‌ی مبلغ بانتی، فرمول ایجاد کردید؟

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

_ کمی بیش‌تر از فرمولی که ایجاد کردید، برامون می‌گی؟ در بررسی‌هایی که بهشون اشاره کردی، به چه معیارهایی رسیدید؟

داستان به این شکل شد که به سه تا ملاک برای تعیین ارزش یک آسیب پذیری رسیدیم، و این شد ایده‌ی اولیه و همون فرمول اولیه‌مون. ملاک اول ما یک قیمت پایه بود. طبق دسته‌بندی‌های جهانی، هر آسیب پذیری‌ در یکی از پنج سطح حیاتی (Critical)، بالا (High) ، متوسط (Medium) ، پایین (Low) و اطلاع‌رسانی (Informative) قرار می‌گیره. ما گفتیم خب هر کدوم از این پنج تا سطحی که مشخصه، می‌تونه معادل میزان خطرش، یک قیمت پایه داشته باشه. این قیمت پایه شد ملاک اول ما. مرحله‌ی بعدی اومدیم گفتیم: "خب. یک آسیب پذیری در سازمان چه تاثیری می‌تونه داشته باشه؟" و با جست‌وجوهایی که انجام دادیم دیدیم که خب بین فرمول‌ها و روال‌های موجود، فرمول CVSS نزدیک‌تر و مطابق‌تر با نیاز ما داره این کار رو انجام می‌ده. CVSS براساس امتیاز پایه، معیارهای زمانی و معیارهای محیطی هر آسیب پذیری یک عدد بین ۰ تا ۱۰ رو از نظر میزان خطر بهش اختصاص می‌ده. خیلی‌ها می‌گن که ما این‌جا داریم هم‌دیگه رو کاور می‌کنیم. چون خروجی CVSS هم یک عدد هست از صفر تا ده. که این صفر تا ده رو می‌تونی نگاشت کنی به بازه‌ی Critical، High، Medium، Low، Informative نگاشت یک‌به‌یک دارن. این‌ شد یکی‌دیگه از معیارهای ما. حتی وقتی شما بری و مقالات جهانی رو هم ببینی، متوجه می‌شی که حتی CVSS هم کامل نیست و متدها و سیستم‌های دیگه‌ای هم وجود داشته. ولی خب CVSS از همه کامل‌تر و مطابق‌تر با نیاز ما بود. یه مشکلی که CVSS داشت، این بود که نمی‌تونست موارد بومی رو پوشش بده. یه سری محصولات هستند که بومی هستند و کاربران زیادی دارند، یا برخی سازمان‌ها هستند که محصولی ندارن اما حساسیت بالایی دارن و اگر حمله‌ای بهشون بشه، به‌اندازه‌ی یک امتیازِ ۱۰ در فرمول CVSS اهمیت داره. به همین دلیل، نیاز به حضور یک معیار دیگه رو در فرمول احساس کردیم. عامل دیگه‌ای رو به بخش تاثیر آسیب‌پذیری اضافه کردیم با اسم " برآورد تخریب ". ۵ تا فاکتور رو در نظر گرفتیم که اون ۵ تا فاکتور برای زیرساخت های بزرگ و حیاتی تیک می‌خورن؛ یعنی یه آسیب پذیری باید حیاتی باشه و میدانش کسب‌وکار بزرگی باشه که بیش از نصف جمعیت کشور ازش استفاده میکنن، یا سازمان ملی و بزرگی مثل وزارتخونه باشه که اون پنج تا سطح تیک بخوره و امتیاز بگیره! نتیجه این دو عامل فرموله. بعد در اظهاراتی که از طرف سازمان‌ها داشتیم می‌دیدیم که یه جای دیگه‌ی کار می‌لنگه، ضریبی اضافه کردیم و اسمش رو گذاشتیم: "ضریب ارزش مجموعه" . این ضریب ارزش مجموعه براساس مواردی مثل اندازه، مقیاس مجموعه توی بازار، حجم فروشش، رتبه‌بندی، تعداد کارکنان و این‌که این سازمان چقدر می‌ارزه، تعیین می‌شه. در زمان پیاده‌سازی، سازمان‌هارو در پنج دسته قرار دادیم و بازه‌ش رو از عدد ۰/۱ گذاشتیم تا ۵. دلیل این‌که اعداد اعشاری زیر ۱ رو هم آوردیم وسط این بود که خب یک سری تیم‌ها استارتاپی یا کوچیک بودند و تازه شروع کرده بودن، اما می‌خواستن توی باگ بانتی بیان. ولی خب قیمتشون در ابعاد سازمان‌ها قرار نمی‌گرفت. ما به همین خاطر یک ضریب اعشاری زیر ۱ گذاشتیم که برای چنین کسب‌وکارهایی استفاده بشه و قیمت رو بشکونه و بیاره پایین، با قرار دادن ماکسیمم مقدارها در این فرمول، عدد ۱۲۵ میلیون خروجی می‌شد و با قرار دادن مینیمم مقدارها، صفر. یعنی این‌طوری بازه‌ی پرداخت بانتی در ایران رو می‌شد یه عدد بین صفر تا ۱۲۵ میلیون تعیین کرد. با این پیش‌بینی‌ها و انتظارها شروع کردیم و پلتفرم توسعه داده شد. ولی جلوتر که رفتیم، دیدیم اون‌جوری که پیش‌بینی می‌کردیم، پیش نمی‌ره.

پیشنهاد خواندنی: ماشین‌حساب CVSS راورو چگونه کار می‌کند؟

_ چطور؟ با چه چالش‌هایی مواجه شدید؟

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

_ در مدل جدیدی که بهش اشاره کردی، دقیقا چطوریه روال ارزش‌گذاری آسیب پذیری ها؟

ما اومدیم یه سری تغییراتی دادیم که نتیجه‌ش شد یه سری اهدافی که الان داریم می‌بینیم، در قسمت قوانین، مشابه قبل آسیب پذیری های مجاز براساس توافقی بین مدیران و تیم فنی و اجرایی شده، مشخصه. ولی ما اومدیم چند دسته آسیب پذیری رو مشخص کردیم و حداکثر بانتی‌ای که به آسیب‌ پذیری از اون نوع تعلق می‌گیره، رو مشخص کردیم. یک سری آسیب پذیری مرتبط رو هم توش گذاشتیم. بعد براساس میدانش، قیمت‌گذاری کردیم که مثلا آسیب پذیری‌های متوسط، حداکثر تا ۵ میلیون، آسیب پذیری‌های سطح بالا حداکثر تا ۱۲ میلیون و ... . تقریبا با یه اختلاف کمی می‌تونیم بگیم اعداد درستی در میاد ازش، اما خب صددرصدی نیست، مثلا؛ شما دو تا هدف بزرگ رو در نظر بگیری که تاثیرشون بالاست و ما حداکثر ۱۲ تومن گذاشتیم و اختلاف‌نظر پیش میاد که کدوم تاثیرش بیشتره و ... . و خب نمی‌تونیم بگیم آسیب پذیری ها صددرصدی دسته بندی شده. هر آسیب پذیری‌ای که امروز گزارش بشه، در یک دسته‌ای قرار می‌گیره. ولی خب فرمول بهتری شده و خیلی نزدیک شده. می‌تونیم بگیم براساس تجربه ۹۰ درصد آسیب های گزارش‌ها رو پوشش می‌ده.

_ این که بعضی اهداف در راورو مدل قیمت‌گذاریشون با اهداف دیگه متفاوته، مربوط به همین تغییر فرمولی می‌شه که گفتی؟

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

_ آها، در مدل قیمت‌گذاری اشاره کردی که حداکثر مبلغی تعیین می‌شه برای آسیب پذیری‌ها. این حداکثر بانتی، مبلغش چطور و توسط چه کسی تعیین می‌شه؟

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

_ یعنی ابتدا و انتهای بازه باتوجه به روال فرمول، تعیین می‌شه. ولی میدان با توجه به سیاست‌ها و شرایط خودش می‌تونه مثل زمان‌‎هایی که استادها نمره‌ها رو روی نمودار می‌برن و همه رو به یه میزان کم و یا زیاد می‌کنن، ارزش باگ‌ها رو کم یا زیاد کنه، یا درخواست چنین کاری رو از راورو داشته باشه؟

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

پیشنهاد خواندنی: مدل پرداختی کسب‌وکار در باگ‌بانتی چگونه است؟

_ یک سوالی که وجود داره اینه که سهم راورو از هر بانتی چقدره؟

ما بابت هر گزارشی که تایید بشه و حالا به پرداخت برسه، ۲۵٪ مازاد اون پاداشی که برای اون اون باگ از قبل تعیین شده و شکارچی قراره دریافت بکندش رو از میدان دریافت می‌کنیم؛ اون می‌شه کارمزد راورو. البته از زمان آغاز کارمون تا حالا این درصد تغییرات زیادی داشته، تا به این درصد رسیده. قراردادهای جدید، همشون ۲۵ درصدند. مثلا اگر یک گزارش آسیب پذیری براساس استانداردها، معادل ۱۰۰ تومن ارزش‌گذاری بشه، ما ۱۲۵ تومن از میدان دریافت می‌کنیم و ۲۵ تومنی که مازاد بر ارزش باگ هست، می‌شه سهم راورو.

_ یعنی ارزش اون باگ دقیقا به‌عنوان بانتی، به شکارچی پرداخت می‌شه. ولی ۲۵ درصد بیش‌تر از میدان دریافت می‌شه برای سهم راورو؟

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

_ راورو به طور کلی از نظر مالیات و کسورات قانونی، چه قوانینی شاملش می‌شه؟

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

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

سوال‌های ما تمام شد. :) شما سوالی در مورد ارزش‌گذاری گزارش‌های آسیب پذیری دارید؟ در قسمت نظرات بپرسید، پاسخ‌گویتان هستیم.

بلاگ‌پست‌های مرتبط:

چرا گزارش‌های آسیب پذیری رد می‌شوند؟ یا به بانتی کمی منجر می‌شوند؟

چرا باید حتما قبل از شکار آسیب پذیری، قوانین هدف را بخوانیم؟