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

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

۱,۲۲۰

بارها گفته‌ایم که یک پلتفرم باگ بانتی مانند پلی میان کسب‌وکارها و تخصص هکرهای کلاه‌سفید است. در این بلاگ‌پست می‌خواهیم برروی معنای "پلتفرم" در این تعریف، دقیق‌تر شویم و راجع به این “پل” و نقشش بیش‌تر بگوییم.

آن‌چه در این بلاگ‌پست خواهید خواند:

• مروری بر معنای پلتفرم

• ویژگی‌های پلتفرم

• تجربه‌های پلتفرمی از زبان کاظم فلاحی

مروری بر معنای پلتفرم

در متمم درباره‌ی پلتفرم این‌گونه نوشته شده است: کلمه‌ی پلتفرم (به انگلیسی: Platform) به معنای سکو است. پلتفرم‌ها سکوهایی هستند که فرصتی برای بهتر دیده‌شدن را در اختیار افراد و کسب‌وکارها قرار می‌دهند.

ویژگی‌های پلتفرم

متمم براساس کتاب انقلاب پلتفرم جفری پارکر، ۴ ویژگی را برای پلتفرم نقل می‌کند:

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

تجربه‌های پلتفرمی از زبان کاظم فلاحی

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

پلتفرم باگ بانتی

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

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

خوش‌بختانه موضوعیه که حرف‌های زیادی برای گفتن می‌شه داشت. :)

چی شد که به فکر راه‌اندازی یک پلتفرم باگ بانتی افتادید؟

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

پس انتخاب کردید که یه پلتفرم بشید؛ یه سکو، یه پل.

آره، ما الان در راورو تلاش می‌کنیم که یک ارتباط برد-برد بین شکارچی آسیب پذیری و کسب‌وکار ایجاد کنیم.

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

آره

به‌عنوان یک پلتفرم، چه زیرساخت‌ها، قوانین و … ای رو ایجاد کردید؟

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

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

به‌طور کلی، راورو در اجرای جریان‌ها، پرداخت‌ها و قیمت‌ها و ... دقیقا چه نقش‌هایی داره؟

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

به بانتی اشاره کردی، راورو در تعیین قیمت‌ بانتی‌ها چه نقشی داره؟

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

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

اگر شکارچی‌ها نسبت به بانتی اختصاص‌داده‌شده، نظر یا اعتراضی داشته باشند، راورو چی‌کار می‌کنه؟

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

راورو کاری کرده برای این‌که مدت زمان بسته‌شدن گزارش ها رو کاهش بده؟

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

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

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

متوجه حرفت هستم. مطمئنا خیلی چالش‌برانگیزه.

من سوال‌هام تموم شد. :) سخن آخری داری؟

آره، می‌خوام بگم که در راورو به‌عنوان یک پلتفرم، یک روبات قرار نگرفته :) یه تیم از افراد قرار دارند که تلاش می‌کنند این روندها رو بهتر شکل بدن. مطمئنا ما بی‌نقص نیستیم، روند کاریمون بی‌نقص نیست و ... . اما به‌طور پیوسته تلاشمون رو می‌کنیم.

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

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

سطح‌بندی و دسته‌بندی شکارچیان در راورو از چه قرار است؟

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

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