Coordinated vulnerability disclosure

مربوط کمزوری افشا (CVD)

سیکیورٹی کمزوریوں کی اطلاع دینے، وصول کرنے اور انہیں مربوط کرنے کا طریقہ، نمونہ پالیسیوں کے ساتھ۔

مربوط کمزوری افشا (Coordinated vulnerability disclosure, CVD) کمپیوٹر سیکیورٹی کی ایک اصطلاح ہے۔ یہ بیان کرتی ہے کہ لوگ سیکیورٹی کے مسائل کے بارے میں رپورٹیں کیسے شیئر کر سکتے ہیں۔ مثالوں میں بگ رپورٹس، دراندازی کے خطرات، ہیکنگ کی وارننگز، ڈیٹا کا افشا، ویب سائٹ کی خلاف ورزیاں وغیرہ شامل ہیں۔

تراجم: العربية, Български, বাংলা, Čeština, Cymraeg, Dansk, Deutsch, Ελληνικά, English, Español, Eesti, Euskara, فارسی, Suomi, Français, Gaeilge, Gàidhlig, ગુજરાતી, Hausa, עברית, हिन्दी, Hrvatski, Magyar, Bahasa Indonesia, Íslenska, Italiano, 日本語, 한국어, Lietuvių, Latviešu, Nederlands, Polski, Português, Română, Русский, Slovenčina, Slovenščina, Svenska, Kiswahili, ไทย, Türkçe, Українська, اردو, Tiếng Việt, 中文

فہرستِ مضامین:

پالیسیاں:

تعارف

یہ دستاویز مربوط کمزوری افشا کو ایسے طریقوں سے بیان کرتی ہے جو لوگوں کو مل کر کام کرنے میں مدد دے سکتے ہیں۔

دستاویز کے مقاصد:

  1. ان لوگوں کی مدد کرنا جو سیکیورٹی کے مسائل دریافت کرتے ہیں اور ان کی اطلاع دینا چاہتے ہیں۔

  2. کمپنیوں کے نمائندوں کو ذمہ دارانہ افشا کی ضروریات، مقاصد، طریقوں اور خاص صورتوں کو سمجھنے میں مدد دینا۔

  3. ریپوزیٹری کے فولڈر میں مربوط کمزوری افشا کی نمونہ پالیسیاں شامل کرنا۔

ہم پل ریکویسٹ، یا GitHub ایشوز، یا security@joelparkerhenderson.com پر ای میل کا خیرمقدم کرتے ہیں۔

مربوط کمزوری افشا کیا ہے؟

مربوط کمزوری افشا تین مراحل بیان کرتا ہے جب کوئی شخص سیکیورٹی کا مسئلہ (جیسے سافٹ ویئر بگ) دریافت کرتا ہے اور اس کی اطلاع تیار کنندہ (جیسے وہ کمپنی جو سافٹ ویئر بناتی ہے) کو دینا چاہتا ہے۔

مراحل:

  1. دریافت کنندہ نیک نیتی سے مسئلے کی نجی طور پر تیار کنندہ کو اطلاع دیتا ہے۔

  2. تیار کنندہ نیک نیتی سے صارفین کی حفاظت کرنے اور مسئلہ حل کرنے کی کوشش کرتا ہے۔

  3. ایک مقررہ مدت کے بعد سیکیورٹی کا مسئلہ عام کر دیا جاتا ہے۔

مرحلہ 1: مسئلے کی اطلاع دیں

مرحلہ 1 دریافت کنندہ کے لیے ہے: نیک نیتی سے مسئلے کی نجی طور پر اطلاع دیں۔

  • اچھا: دریافت کنندہ متعلقہ معلومات تیار کنندہ کو بھیجتا ہے، جیسے تیار کنندہ کے سیکیورٹی ای میل پتے پر ای میل کے ذریعے (عموماً "security@example.com") یا تیار کنندہ کی ویب سائٹ پر ویب صفحے کے فارم کے ذریعے (عموماً "https://www.example.com/security")۔

  • برا: رپورٹ کو عوامی بلاگ پر پوسٹ کرنا، یا میڈیا کو خبردار کرنا، یا دھمکیاں دینا، یا سیکیورٹی کا مسئلہ ہیکرز کو بیچنے کی کوشش کرنا وغیرہ۔

  • مشورہ: دریافت کنندہ گمنام رہنے کا انتخاب کر سکتا ہے؛ تیار کنندہ بھی گمنام رہنے کا انتخاب کر سکتا ہے۔

اگر چاہیں تو مسئلے سے باخبر رہنا جاری رکھیں۔

  • اچھا: رابطے کے راستے کھلے رکھنا، یا فالو اپ معلومات فراہم کرنا، یا صورتحال کی نگرانی کرنا۔

  • برا: مسئلے کو بھول جانا۔

  • مشورہ: دریافت کنندہ مدد کرنے یا نہ کرنے کا انتخاب کر سکتا ہے، اور رابطے میں رہنے یا نہ رہنے کا بھی، اور حالات بدلنے پر انتظام بدلنے کا بھی انتخاب کر سکتا ہے۔

اگر چاہیں تو مسئلہ دوسروں پر ظاہر کریں۔

  • اچھا: مقررہ مدت انتظار کر کے عام کرنا، جیسے متعلقہ معلومات کسی سیکیورٹی نیوز سائٹ پر پوسٹ کرنا، یا متعلقہ تیسرے فریق کے سیکیورٹی محققین سے رابطہ کرنا، یا کسی بھی عوامی سوشل سائٹ پر مسئلے کا اعلان کرنا وغیرہ۔

  • برا: مسئلہ دوسروں پر ظاہر نہ کرنا، الا یہ کہ آپ محسوس کریں کہ اس سے آپ کو یا دوسروں کو متناسب مقدار سے زیادہ خطرہ ہوگا۔

  • مشورہ: اگر حالات بدل جائیں، جیسے زیادہ خطرے یا حقیقی دنیا میں فعال ایکسپلائٹ (active exploit in the wild) کا پتا چلنا، تو دریافت کنندہ مسئلہ دوسروں پر جلد ظاہر کر سکتا ہے۔

مرحلہ 2: رابطے یقینی بنائیں

مرحلہ 2 تیار کنندہ کے لیے ہے: یقینی بنائیں کہ رابطے کارآمد ہیں۔

  • اچھا: تیار کنندہ سیکیورٹی رابطے کا ای میل پتہ شائع کرتا ہے (روایتاً "security@example.com") اور مثالی طور پر ای میل انکرپشن کی محفوظ کلید بھی۔

  • اچھا: تیار کنندہ سیکیورٹی رابطے کا ویب صفحہ شائع کرتا ہے (روایتاً "https://www.example.com/security") اور مثالی طور پر صفحے کو آسانی سے دریافت کے قابل بناتا ہے، جیسے ویب سائٹ کے فوٹر، سائٹ میپ اور تلاش کے ذریعے۔

  • برا: تیار کنندہ ای میل پتہ یا ویب صفحہ فراہم نہیں کرتا، یا انہیں آسانی سے دریافت کے قابل نہیں بناتا۔

عملے کی صلاحیتیں یقینی بنائیں۔

  • اچھا: تیار کنندہ معاون عملے کو تربیت دیتا ہے کہ سیکیورٹی کی پوچھ گچھ ملنے پر کیا کرنا ہے، جیسے رابطے کی معلومات کے ساتھ جواب کیسے دینا ہے، یا پوچھ گچھ کو درست اندرونی ٹیم کو کیسے آگے بھیجنا ہے۔

  • اچھا: تیار کنندہ وقتاً فوقتاً تصدیق کرتا ہے کہ عملے کی صلاحیتیں کام کر رہی ہیں۔

  • برا: تیار کنندہ تربیت نہیں دیتا یا تصدیق نہیں کرتا۔

مقررہ مدت کے اندر دریافت کنندہ کو جواب دیں۔

  • اگر دریافت کنندہ مدت متعین نہیں کرتا تو ایک کاروباری دن استعمال کریں، کیونکہ یہ صنعت کا معیار اور صنعت کا موجودہ بہترین طریقہ ہے۔

  • اگر دریافت کنندہ سوال پوچھے تو ان کے جواب دیں۔ یہ خاص طور پر اہم ہے اگر دریافت کنندہ جانچ کی اجازت مانگے۔ یقینی بنائیں کہ تمام جوابات واضح اور براہ راست ہوں۔

مجاز سیکیورٹی رابطے اور/یا مجاز سیکیورٹی عمل کے ذریعے دریافت کنندہ کو جواب دیں۔

  • اچھا: سیکیورٹی کے لیے مخصوص ای میل پتے سے جواب، جیسے "security@example.com"۔

  • مثال کے طور پر یہ برا ہے: عام مقصد کے ای میل پتے سے جواب، جیسے "help@example.com"، یا کسی ایسے شخص سے جو مجاز سیکیورٹی پروفیشنل نہیں۔

دریافت کنندہ کو بتائیں کہ مسئلے کو سیکیورٹی رپورٹ کے طور پر تسلیم کر لیا گیا ہے۔

  • اچھا: سیکیورٹی کے لیے مخصوص الفاظ، جیسے "ہماری سیکیورٹی ٹیم کو آپ کی ذمہ دارانہ افشا کی رپورٹ موصول ہو گئی ہے"، یا "ہمارے سیکیورٹی عمل میں یہ اگلے مراحل ہیں"، یا "آپ کی معلومات اب ہمارے سیکیورٹی ٹریکر میں آئی ڈی نمبر XYZ کے ساتھ ہیں" وغیرہ۔

  • برا: عام مقصد کے الفاظ، جیسے "ہم آپ کے کاروبار کی قدر کرتے ہیں"، یا "ہم سیکیورٹی کو سنجیدگی سے لیتے ہیں"، ذمہ داری ٹالنے والے الفاظ جیسے "ہم نے آپ کی ای میل دوسرے شعبے کو بھیج دی" وغیرہ۔

مرحلہ 3: نیک نیتی سے کام کریں

مرحلہ 3 دریافت کنندہ اور تیار کنندہ دونوں کے مل کر کرنے کے لیے ہے: نیک نیتی سے کام کریں۔

سمجھیں کہ مربوط کمزوری افشا ایک نیک نیتی کا عمل بیان کرتا ہے۔

  • مقصد نمبر 1 صارفین کو سیکیورٹی خطرات سے اپنی حفاظت کرنے میں نیک نیتی سے مدد دینا ہے۔

  • مقصد نمبر 2 سیکیورٹی مسئلہ حل کرنے کی نیک نیتی ہے۔

  • دریافت کنندہ اور/یا تیار کنندہ نیک نیتی سے دوسرے سیکیورٹی افراد کو شامل کرنے کا انتخاب کر سکتے ہیں، جیسے مسئلے میں مدد کے لیے دوسرے متعلقہ سیکیورٹی محققین سے رابطہ کرنا۔

سمجھیں کہ مربوط کمزوری افشا کوئی ذمہ داری عائد نہیں کرتا۔

  • دریافت کنندہ اور/یا تیار کنندہ کسی بھی وقت، کسی بھی وجہ سے، انتباہ کے ساتھ یا بغیر الگ ہو سکتے ہیں۔ تمام متعلقہ لوگوں کو باخبر اور تازہ ترین رکھنا شائستگی ہے، لیکن یہ ہمیشہ ممکن، عملی یا مطلوب نہیں ہوتا۔

  • مربوط کمزوری افشا کوئی قانونی معاہدہ نہیں بناتا۔ اگر دریافت کنندہ اور تیار کنندہ کے درمیان پہلے سے قانونی معاہدہ ہے تو ہم تجویز کرتے ہیں کہ تمام متعلقہ لوگ مناسب وکلا سے مشورہ کریں؛ اس دستاویز کو قانونی مشورے کے طور پر استعمال نہ کریں۔

سمجھیں کہ مربوط کمزوری افشا اچھی بات چیت استعمال کرنے اور دھمکیوں کو مسترد کرنے کا ہدف رکھتا ہے۔

  • مربوط کمزوری افشا اس وقت بہترین ہوتا ہے جب تمام متعلقہ لوگ سمجھیں کہ مقصد نمبر 1 صارفین کو سیکیورٹی خطرات سے اپنی حفاظت میں مدد دینا ہے، اور مقصد نمبر 2 سیکیورٹی مسئلہ حل کرنا ہے۔

  • مربوط کمزوری افشا انتقام، ڈرانے دھمکانے، معطلی، منسوخی، بھتہ خوری، فالو اپ کا بوجھ، یا متاثرہ کو مورد الزام ٹھہرانے کی ہر قسم کی دھمکی کو مسترد کرتا ہے۔

سمجھیں کہ مربوط کمزوری افشا مختلف لوگوں کے لیے مختلف معنی رکھ سکتا ہے۔

  • دریافت کنندہ اور تیار کنندہ کی مربوط کمزوری افشا کے بارے میں سمجھ مختلف ہو سکتی ہے۔ یہ سمجھ ایک دوسرے سے مطابقت نہ رکھتی ہو۔ نیک نیتی میں تمام متعلقہ لوگوں کا یہ بات سمجھنا شامل ہے۔

  • کچھ تیار کنندگان مربوط کمزوری افشا کی پالیسیاں شائع کرتے ہیں۔ یہ مددگار رہنمائی ہو سکتی ہیں۔ اگر دریافت کنندہ مربوط کمزوری افشا کی کوئی مختلف قسم استعمال کرنے کا انتخاب کرے، یا ذمہ دارانہ افشا کی مختلف سمجھ رکھتا ہو، تو یہ بالکل ٹھیک ہے۔

سمجھیں کہ عموماً دریافت کنندہ ناشر پر احسان کر رہا ہوتا ہے۔

  • عموماً دریافت کنندہ کو کمزوریاں شائع کرنے کے لیے کسی کی اجازت درکار نہیں ہوتی۔

  • عموماً دریافت کنندہ کی معلومات ناشر کی مدد کرتی ہیں۔

کامیابی کی تصدیق کریں

مسئلہ حل ہونے کے بعد تیار کنندہ کو کامیابی کی تصدیق کرنی چاہیے۔

  • کیا تمام لوگوں اور عملوں نے افشا کو کامیابی سے سنبھالا؟ اگر ہاں تو اچھا۔ اگر نہیں تو بعد از واقعہ تحقیق پر غور کریں، جیسے جڑ کی وجہ کا تجزیہ (RCA)، پوسٹ مارٹم رپورٹیں، اشیکاوا ڈایاگرام، یا نظامی نظریے پر مبنی سببی تجزیہ (CAST)۔

  • کیا باقی ماندہ مسائل کی ترجیح بندی کر کے انہیں ٹریک کیا جا رہا ہے؟

  • کیا تیار کنندہ اور دریافت کنندہ دونوں سمجھتے ہیں کہ کسی بھی اگلے مرحلے کے لیے کیا کرنا ہے؟ اسے درست کرنا خاص طور پر اہم ہے اگر آگے مزید مربوط کمزوری افشا ہو سکتے ہوں۔

رہنمائی

مربوط کمزوری افشا کی رہنمائی کئی شعبوں سے آ سکتی ہے، جیسے اخلاقیات کے ماہرین، قانونی وکالت کرنے والے، عام عوام کی معقول توقعات وغیرہ۔

اگر آپ رہنمائی تلاش کر رہے ہیں تو آپ ان تین شعبوں میں دلچسپی رکھ سکتے ہیں، جو سب نیچے بیان کیے گئے ہیں۔

  • اچھا سامری

  • بچانے کی ذمہ داری

  • احتیاط کی ذمہ داری

اچھا سامری

Wikipedia: اچھے سامری کا قانون

اچھے سامری کے قوانین (Good Samaritan laws) ان لوگوں کو قانونی تحفظ دیتے ہیں جو ان افراد کو معقول مدد فراہم کرتے ہیں جو زخمی، بیمار، خطرے میں، یا بصورت دیگر معذور ہوں، یا جن کے بارے میں وہ ایسا سمجھتے ہوں۔ اس تحفظ کا مقصد مقدمے یا استغاثے کے خوف سے آس پاس کے لوگوں کی مدد کرنے میں ہچکچاہٹ کو کم کرنا ہے۔

بچانے کی ذمہ داری

Wikipedia: بچانے کی ذمہ داری

بچانے کی ذمہ داری ایک تصور ہے جو ایسی صورت حال بیان کرتا ہے جس میں کوئی فریق خطرے میں گھرے دوسرے فریق کو بچانے میں ناکامی پر ذمہ دار ٹھہرایا جا سکتا ہے۔ بچانے کی ذمہ داری کے اخلاقی اور/یا قانونی دائرے ہو سکتے ہیں۔

احتیاط کی ذمہ داری

Wikipedia: احتیاط کی ذمہ داری

احتیاط کی ذمہ داری کسی بھی ایسے عمل کو انجام دیتے وقت معقول احتیاط کے معیار کی پابندی کی ذمہ داری ہے جو دوسروں کو متوقع طور پر نقصان پہنچا سکتا ہو۔ احتیاط کی ذمہ داری کے اخلاقی اور/یا قانونی دائرے ہو سکتے ہیں۔ غور کرنے کے کچھ پہلو یہ ہیں: نقصان یا چوٹ کی پیش بینی کی صلاحیت، ممکنہ نقصان یا چوٹ کی ممکنہ وسعت، مدعا علیہ جس سرگرمی میں مصروف تھا اس کی اہمیت یا سماجی قدر، مدعا علیہ کے لیے اس طرز عمل کی افادیت، متبادل طرز عمل کی عملی صلاحیت، متبادل طرز عمل سے وابستہ لاگت اور بوجھ، متبادل طرز عمل کی اضافی افادیت، اور متبادل طرز عمل کی اضافی حفاظت۔

خاص صورتیں

ہماری سیکیورٹی ٹیموں نے خاص صورتوں کی ایک وسیع رینج دیکھی ہے۔

ہم انہیں یہاں اس لیے بیان کرتے ہیں کہ لوگوں کو سمجھنے میں مدد ملے کہ کہاں اس بارے میں آرا کی وسیع رینج ہے کہ کیا ٹھیک ہو سکتا ہے اور کیا ٹھیک نہیں ہو سکتا۔ ہم تجویز کرتے ہیں کہ تمام متعلقہ لوگ ان کے بارے میں نیک نیتی سے بات چیت کریں۔

دوسرے صارفین کی معلومات تک رسائی

مثال: آپ دریافت کرتے ہیں کہ ایک URL میں آپ کی صارف آئی ڈی ہے، اور وہ ایک بگ ظاہر کرتی ہے، اور آپ سمجھتے ہیں کہ آپ URL میں ترمیم کر کے اپنی صارف آئی ڈی کو کسی دوسرے صارف کی آئی ڈی میں بدل سکتے ہیں۔

  • کیا دریافت کنندہ کا ایسا کرنا ٹھیک ہے، جیسے محض یہ دریافت کرنے کے مقصد سے کہ آیا یہ دوسرے صارفین کو بھی متاثر کر رہا ہے؟

  • کیا تمام صارفین کے لیے خطرے کی وسعت کو جلدی سمجھنا ان چند صارفین کی حفاظت سے زیادہ اہم ہے جن کی معلومات شاید پہلے ہی ہیکرز کو نظر آ رہی ہوں؟

  • کیا دریافت کنندہ کا جتنے صارفین پر چاہے ایسا کرنا ٹھیک ہے؟

  • کیا دریافت کنندہ کا صارفین کو بتانے کے لیے رابطے کی کوشش کرنا ٹھیک ہے کہ وہ متاثر ہیں؟ کیا تخفیف کے مشورے دینا ٹھیک ہے؟

سروس سے انکار

مثال: آپ ایک بگ دریافت کرتے ہیں جو حادثاتی طور پر آپ کا اکاؤنٹ معطل کر دیتا ہے، جیسے پاس ورڈ لاک کو متحرک کرنا۔

  • کیا اسے سروس سے انکار (denial of service) کا حملہ سمجھا جاتا ہے؟

غیر مطلوب ای میل

مثال: آپ کمپنی میں ان لوگوں کو سیکیورٹی مسئلے کی اطلاع دینے کی کوشش کرتے ہیں جنہیں آپ متعلقہ سمجھتے ہیں، اور جنہیں آپ LinkedIn، Facebook وغیرہ پر تحقیق کر کے، یا "webmaster@example.com" یا "security@example.com" جیسے نام رکھنے کے اصول استعمال کر کے دریافت کرتے ہیں۔

  • کیا یہ ٹھیک ہے؟

  • کیا اسے غیر مطلوب ای میل (unsolicited email) سمجھا جاتا ہے؟

  • کیا اسے غیر مجاز ای میل (unauthorized email) سمجھا جاتا ہے؟

خارج کردہ گروہ

مثال: آپ کسی خارج کردہ گروہ میں ہیں، جیسے نابالغ ہونا، یا پابندیوں کی فہرست میں ہونا، یا پابندیوں کی فہرست والے ملک میں ہونا۔

  • کیا آپ کا رپورٹ کرنا ٹھیک ہے؟

  • کیا گمنام طور پر رپورٹ کرنا ٹھیک ہے؟

  • کیا خارج کردہ گروہ سے بچنے کے لیے، اور افشا کو درست لوگوں تک پہنچانے کے مقصد سے، ممکنہ طور پر شناخت کرنے والی معلومات کو جان بوجھ کر بدلنا ٹھیک ہے؟

تیسرا فریق

مثال: آپ دریافت کرتے ہیں کہ کسی کمپنی کے سافٹ ویئر میں ایک بگ ہے جس میں تیسرا فریق شامل ہے، جیسے کسی دوسرے سافٹ ویئر یا دوسری ویب سائٹ کے ساتھ انضمام۔

  • کیا آپ کا پائی جانے والی تمام معلومات دونوں فریقوں کو رپورٹ کرنا ٹھیک ہے؟

  • کیا دو مختلف ذمہ دارانہ افشا کرنا ضروری ہے، جیسے ایک رپورٹ ایک کمپنی کو، اور مختلف رپورٹ تیسرے فریق کی کمپنی کو، ہر کمپنی کو بھیجی جانے والی معلومات کو محدود کرنے کے مقصد سے؟

  • کیا دریافت کنندہ کا کمپنیوں کو ایک دوسرے سے رابطے میں لانا ٹھیک ہے؟

خلل ڈالنے والا سافٹ ویئر

مثال: آپ اتنے ماہر ہیں کہ ایک وائرس لکھ سکتے ہیں جس کے بارے میں آپ سمجھتے ہیں کہ وہ صارفین کو سیکیورٹی خطرے سے اپنی حفاظت کرنے، یا یہ شناخت کرنے کہ آیا وہ خطرے میں ہیں، یا سیکیورٹی خطرے کو ٹھیک کرنے میں مدد دے گا۔

  • کیا یہ ٹھیک ہے؟

  • کیا دریافت کنندہ کا صارفین کو ایسے سافٹ ویئر کی طرف، اور/یا ایسی گائیڈز یا ٹیوٹوریلز کی طرف رہنمائی کرنا ٹھیک ہے جو اس قسم کا سافٹ ویئر بنانے کا طریقہ بیان کرتی ہیں؟

مربوط کمزوری افشا بمقابلہ ذمہ دارانہ افشا

مربوط کمزوری افشا ترجیحی اصطلاح ہے۔

  • سب سے اہم پہلو دریافت کنندہ اور تیار کنندہ کے درمیان ہم آہنگی ہے۔

ذمہ دارانہ افشا (responsible disclosure) ایک متروک اصطلاح ہے۔

  • ذمہ دار ہونے کا کیا مطلب ہے، اس بارے میں لوگوں کے نقطہ نظر مختلف ہیں۔ مثال کے طور پر، کچھ لوگ وکالت کرتے ہیں کہ تیار کنندہ کے ساتھ کسی بھی تعامل سے قطع نظر عوام کو فوراً مطلع کرنا دریافت کنندہ کی ذمہ داری ہے، اور مربوط کمزوری افشا کرنا غیر ذمہ دارانہ ہے کیونکہ یہ عوام سے معلومات چھپاتا ہے۔

ٹریکنگ