ہمارے پاس 2 کوڈ اینالائزر، 4 ڈائنامک ٹیسٹنگ ٹولز، ہمارے اپنے دستکاری اور 250 اسکرپٹ تھے۔ ایسا نہیں ہے کہ موجودہ عمل میں اس سب کی ضرورت ہے، لیکن ایک بار جب آپ DevSecOps کو لاگو کرنا شروع کر دیتے ہیں، تو آپ کو آخر تک جانا ہوگا۔
. کریکٹر کریڈٹ: جسٹن رولینڈ اور ڈین ہارمون۔
SecDevOps کیا ہے؟ DevSecOps کے بارے میں کیا خیال ہے؟ اختلافات کیا ہیں؟ ایپلیکیشن سیکیورٹی - یہ کیا ہے؟ کلاسک نقطہ نظر اب کام کیوں نہیں کرتا؟ ان تمام سوالوں کا جواب جانتا ہے۔ یوری شبالین کی سوارڈ فش سیکیورٹی۔ یوری ہر چیز کا تفصیل سے جواب دے گا اور کلاسک ایپلیکیشن سیکیورٹی ماڈل سے DevSecOps عمل میں منتقلی کے مسائل کا تجزیہ کرے گا: ڈیو اوپس کے عمل میں محفوظ ترقی کے عمل کے انضمام تک صحیح طریقے سے کیسے رجوع کیا جائے اور کسی چیز کو نہ توڑا جائے، اہم مراحل سے کیسے گزرنا ہے۔ سیکیورٹی ٹیسٹنگ، کون سے ٹولز استعمال کیے جاسکتے ہیں، اور وہ کیا مختلف ہیں اور نقصانات سے بچنے کے لیے انہیں صحیح طریقے سے کیسے ترتیب دیا جائے۔
اسپیکر کے بارے میں: یوری شبالین - کمپنی میں چیف سیکیورٹی آرکیٹیکٹ سوارڈ فش سیکیورٹی. SSDL کے نفاذ کے لیے ذمہ دار ہے، ایک واحد ترقی اور جانچ کے ماحولیاتی نظام میں ایپلیکیشن تجزیہ کے ٹولز کے مجموعی انضمام کے لیے۔ معلومات کی حفاظت میں 7 سال کا تجربہ۔ Alfa-Bank، Sberbank اور Positive Technologies میں کام کیا، جو سافٹ ویئر تیار کرتا ہے اور خدمات فراہم کرتا ہے۔ بین الاقوامی کانفرنسوں ZerONights، PHDays، RISSPA، OWASP میں اسپیکر۔
ایپلی کیشن سیکیورٹی: اس کے بارے میں کیا ہے؟
درخواست سیکورٹی سیکیورٹی سیکشن ہے جو ایپلیکیشن سیکیورٹی کے لیے ذمہ دار ہے۔ اس کا تعلق انفراسٹرکچر یا نیٹ ورک سیکیورٹی سے نہیں ہے، بلکہ اس سے ہے کہ ہم کیا لکھ رہے ہیں اور جس پر ڈویلپر کام کر رہے ہیں - یہ خود ایپلی کیشن کی خامیاں اور کمزوریاں ہیں۔
سمت - سیکورٹی ترقی کی زندگی سائیکل - مائیکروسافٹ کے ذریعہ تیار کردہ۔ یہ خاکہ کینونیکل SDLC ماڈل کو دکھاتا ہے، جس کا بنیادی کام ترقی کے ہر مرحلے پر، ضروریات سے لے کر پیداوار میں ریلیز ہونے تک سیکورٹی کی شرکت ہے۔ مائیکروسافٹ نے محسوس کیا کہ انڈسٹری میں بہت زیادہ کیڑے ہیں، ان میں سے بہت زیادہ ہیں اور اس کے بارے میں کچھ کرنا ہے، اور انہوں نے یہ نقطہ نظر تجویز کیا، جو کیننیکل بن گیا ہے۔
ایپلیکیشن سیکیورٹی اور ایس ایس ڈی ایل کا مقصد کمزوریوں کا پتہ لگانا نہیں ہے، جیسا کہ عام طور پر خیال کیا جاتا ہے، بلکہ ان کی موجودگی کو روکنا ہے۔ وقت گزرنے کے ساتھ ساتھ، مائیکروسافٹ کے کینونیکل اپروچ کو بہتر بنایا گیا ہے، تیار کیا گیا ہے، اور ایک گہرے، مزید تفصیلی غوطہ میں متعارف کرایا گیا ہے۔
کینونیکل SDLC مختلف طریقوں - OpenSAMM، BSIMM، OWASP میں انتہائی مفصل ہے۔ طریقہ کار مختلف ہیں، لیکن عام طور پر ایک جیسے ہیں۔
میچورٹی ماڈل میں سیکیورٹی کی تعمیر
مجھے یہ سب سے اچھا لگتا ہے۔ بی ایس آئی ایم ایم - . طریقہ کار کی بنیاد ایپلی کیشن سیکیورٹی کے عمل کو 4 ڈومینز میں تقسیم کرنا ہے: گورننس، انٹیلی جنس، SSDL ٹچ پوائنٹس اور تعیناتی۔ ہر ڈومین میں 12 مشقیں ہوتی ہیں، جن کی نمائندگی 112 سرگرمیوں کی شکل میں ہوتی ہے۔
112 سرگرمیوں میں سے ہر ایک میں ہے۔ پختگی کی 3 سطحیں۔: ابتدائی، انٹرمیڈیٹ اور ایڈوانس۔ تمام 12 طریقوں کا سیکشنز میں مطالعہ کیا جا سکتا ہے، ان چیزوں کا انتخاب کرنا جو آپ کے لیے اہم ہیں، ان پر عمل درآمد کرنے کا طریقہ معلوم کرنا اور بتدریج عناصر شامل کرنا، مثال کے طور پر، جامد اور متحرک کوڈ کا تجزیہ یا کوڈ کا جائزہ۔ آپ ایک منصوبہ لکھتے ہیں اور منتخب سرگرمیوں کو نافذ کرنے کے فریم ورک کے اندر سکون سے اس کے مطابق کام کرتے ہیں۔
DevSecOps کیوں؟
DevOps ایک مجموعی طور پر بڑا عمل ہے جس میں سیکیورٹی کا خیال رکھنے کی ضرورت ہے۔
شروع میں شامل حفاظتی چیک عملی طور پر، سیکیورٹی ٹیموں کی تعداد اب کی نسبت بہت کم تھی، اور انہوں نے اس عمل میں حصہ لینے والوں کے طور پر نہیں، بلکہ ایک کنٹرول اور نگران ادارے کے طور پر کام کیا جو اس پر تقاضے عائد کرتا ہے اور مصنوعات کے معیار کی جانچ کرتا ہے۔ رہائی. یہ ایک کلاسک نقطہ نظر ہے جس میں سیکیورٹی ٹیمیں ترقی سے دیوار کے پیچھے تھیں اور اس عمل میں حصہ نہیں لیا۔
بنیادی مسئلہ یہ ہے کہ معلومات کی حفاظت ترقی سے الگ ہے۔ عام طور پر یہ کسی قسم کا انفارمیشن سیکیورٹی سرکٹ ہوتا ہے اور اس میں 2-3 بڑے اور مہنگے ٹولز ہوتے ہیں۔ ہر چھ ماہ میں ایک بار، سورس کوڈ یا ایپلیکیشن چیک کرنے کے لیے آتے ہیں، اور سال میں ایک بار وہ تیار کیے جاتے ہیں۔ . یہ سب اس حقیقت کی طرف جاتا ہے کہ انڈسٹری کے لیے ریلیز کی تاریخ ملتوی کر دی گئی ہے، اور ڈویلپر کو خودکار ٹولز سے بڑی تعداد میں خطرات لاحق ہیں۔ ان سب کو الگ کرنا اور مرمت کرنا ناممکن ہے، کیونکہ انہوں نے پچھلے چھ ماہ کے نتائج کو ترتیب نہیں دیا ہے، لیکن یہاں ایک نیا بیچ ہے۔
ہماری کمپنی کے کام کے عمل میں، ہم دیکھتے ہیں کہ تمام شعبوں اور صنعتوں میں سیکیورٹی سمجھتی ہے کہ اب وقت آگیا ہے کہ ایک پہیے پر ترقی کے ساتھ آگے بڑھیں۔ . DevSecOps پیراڈیم ہر ریلیز اور تکرار میں فرتیلی ترقی کے طریقہ کار، نفاذ، تعاون اور شرکت کے ساتھ بالکل فٹ بیٹھتا ہے۔
DevSecOps میں منتقلی۔
سیکیورٹی ڈیولپمنٹ لائف سائیکل میں سب سے اہم لفظ ہے۔ "عمل". ٹولز خریدنے کے بارے میں سوچنے سے پہلے آپ کو اسے سمجھنا چاہیے۔
DevOps کے عمل میں صرف ٹولز کو شامل کرنا کافی نہیں ہے — عمل کے شرکاء کے درمیان مواصلت اور افہام و تفہیم ضروری ہے۔
لوگ زیادہ اہم ہیں، اوزار نہیں۔
اکثر، محفوظ ترقی کے عمل کے لیے منصوبہ بندی ایک ٹول کے انتخاب اور خریداری کے ساتھ شروع ہوتی ہے، اور اس آلے کو موجودہ عمل میں ضم کرنے کی کوششوں پر ختم ہوتی ہے، جو کوششیں رہتی ہیں۔ یہ افسوسناک نتائج کی طرف جاتا ہے، کیونکہ تمام آلات کی اپنی خصوصیات اور حدود ہیں۔
ایک عام معاملہ ہے جب سیکورٹی ڈیپارٹمنٹ نے وسیع صلاحیتوں کے ساتھ ایک اچھے، مہنگے ٹول کا انتخاب کیا، اور اسے اس عمل میں ضم کرنے کے لیے ڈویلپرز کے پاس آیا۔ لیکن یہ کام نہیں کرتا ہے - اس عمل کو اس طرح بنایا گیا ہے کہ پہلے سے خریدے گئے ٹول کی حدود موجودہ پیراڈائم میں فٹ نہیں ہوتی ہیں۔
سب سے پہلے، بیان کریں کہ آپ کیا نتیجہ چاہتے ہیں اور عمل کیسا نظر آئے گا۔ اس سے آپ کو اس عمل میں ٹول اور سیکیورٹی کے کردار کو سمجھنے میں مدد ملے گی۔
اس سے شروع کریں جو پہلے سے استعمال میں ہے۔
مہنگے اوزار خریدنے سے پہلے، دیکھیں کہ آپ کے پاس پہلے سے کیا ہے۔ ہر کمپنی کی ترقی کے لیے حفاظتی تقاضے ہوتے ہیں، وہاں چیکس، پینٹیسٹ ہوتے ہیں - کیوں نہ ان سب کو سب کے لیے قابل فہم اور آسان شکل میں تبدیل کیا جائے؟
عام طور پر تقاضے ایک کاغذ تلمود ہوتے ہیں جو شیلف پر بیٹھتے ہیں۔ ایک ایسا معاملہ تھا جب ہم پروسیس کو دیکھنے کے لیے ایک کمپنی کے پاس آئے اور سافٹ ویئر کے لیے سیکیورٹی کے تقاضے دیکھنے کو کہا۔ اس سے نمٹنے والے ماہر نے ایک طویل وقت تلاش کیا:
- اب، نوٹوں میں کہیں ایک راستہ تھا جہاں یہ دستاویز موجود ہے۔
نتیجے کے طور پر، ہمیں ایک ہفتہ بعد دستاویز موصول ہوئی۔
ضروریات، چیک وغیرہ کے لیے، مثال کے طور پر ایک صفحہ بنائیں سنگم - یہ سب کے لئے آسان ہے.
جو آپ کے پاس پہلے سے موجود ہے اسے دوبارہ فارمیٹ کرنا اور اسے شروع کرنے کے لیے استعمال کرنا آسان ہے۔
سیکیورٹی چیمپئنز کا استعمال کریں۔
عام طور پر، ایک اوسط کمپنی میں، 100-200 ڈویلپرز کے لیے، ایک سیکیورٹی ماہر ہوتا ہے جو کئی کام کرتا ہے اور جسمانی طور پر ہر چیز کو چیک کرنے کا وقت نہیں رکھتا۔ یہاں تک کہ اگر وہ اپنی پوری کوشش کرتا ہے، تو وہ اکیلے ان تمام کوڈ کی جانچ نہیں کرے گا جو ترقی پیدا کرتا ہے۔ ایسے معاملات کے لیے ایک تصور تیار کیا گیا ہے۔ .
سیکیورٹی چیمپئنز ترقیاتی ٹیم کے اندر وہ لوگ ہوتے ہیں جو آپ کے پروڈکٹ کی سیکیورٹی میں دلچسپی رکھتے ہیں۔
سیکیورٹی چیمپیئن ترقیاتی ٹیم میں داخل ہونے کا ایک نقطہ ہے اور ایک سیکیورٹی مبشر کو شامل کیا گیا ہے۔
عام طور پر، جب کوئی سیکیورٹی ماہر ترقیاتی ٹیم کے پاس آتا ہے اور کوڈ میں غلطی کی نشاندہی کرتا ہے، تو اسے حیران کن جواب ملتا ہے:
- اور تم کون ہو؟ میں آپ کو پہلی بار دیکھ رہا ہوں۔ میرے ساتھ سب کچھ ٹھیک ہے - میرے سینئر دوست نے مجھے کوڈ کے جائزے پر "درخواست" دیا، ہم آگے بڑھتے ہیں!
یہ ایک عام صورت حال ہے، کیونکہ ٹیم کے سینئرز یا محض ساتھیوں پر بہت زیادہ بھروسہ ہوتا ہے جن کے ساتھ ڈویلپر کام پر اور کوڈ کے جائزے میں مسلسل بات چیت کرتا ہے۔ اگر سیکورٹی آفیسر کے بجائے سیکورٹی چیمپیئن غلطی اور نتائج کی نشاندہی کرے تو اس کی بات میں زیادہ وزن ہوگا۔
نیز، ڈویلپرز اپنے کوڈ کو کسی بھی سیکیورٹی ماہر سے بہتر جانتے ہیں۔ ایک ایسے شخص کے لیے جس کے پاس جامد تجزیہ کے آلے میں کم از کم 5 پروجیکٹس ہیں، عام طور پر تمام باریکیوں کو یاد رکھنا مشکل ہوتا ہے۔ سیکیورٹی چیمپیئن اپنی مصنوعات کو جانتے ہیں: کیا چیز کے ساتھ تعامل کرتا ہے اور پہلے کس چیز کو دیکھنا ہے - وہ زیادہ موثر ہیں۔
لہذا سیکیورٹی چیمپئنز کو نافذ کرنے اور اپنی سیکیورٹی ٹیم کے اثر و رسوخ کو بڑھانے پر غور کریں۔ یہ خود چیمپیئن کے لیے بھی مفید ہے: ایک نئے شعبے میں پیشہ ورانہ ترقی، اس کے تکنیکی افق کو وسعت دینا، تکنیکی، انتظامی اور قائدانہ صلاحیتوں کو اپ گریڈ کرنا، مارکیٹ ویلیو میں اضافہ۔ یہ سوشل انجینئرنگ کا کچھ عنصر ہے، ترقیاتی ٹیم میں آپ کی "آنکھیں"۔
جانچ کے مراحل
بیان کرتا ہے کہ 20% کوششیں 80% نتائج دیتی ہیں۔ یہ 20% ایپلیکیشن کے تجزیہ کے طریقے ہیں جو خودکار ہوسکتے ہیں اور ہونے چاہئیں۔ اس طرح کی سرگرمیوں کی مثالیں جامد تجزیہ ہیں۔ SAST, متحرک تجزیہ - ڈسٹ и اوپن سورس کنٹرول. میں آپ کو سرگرمیوں کے ساتھ ساتھ ان ٹولز کے بارے میں مزید بتاؤں گا کہ اس عمل میں متعارف کراتے وقت ہمیں عام طور پر کن خصوصیات کا سامنا کرنا پڑتا ہے، اور اسے صحیح طریقے سے کیسے کرنا ہے۔
اوزار کے اہم مسائل
میں ان مسائل کو اجاگر کروں گا جو تمام آلات کے لیے متعلقہ ہیں اور جن پر توجہ کی ضرورت ہے۔ میں ان کا مزید تفصیل سے تجزیہ کروں گا تاکہ اپنے آپ کو مزید نہ دہرایا جائے۔
طویل تجزیہ کا وقت۔ اگر تمام ٹیسٹوں اور اسمبلی کے لیے ریلیز ہونے کے لیے کمٹمنٹ سے 30 منٹ لگتے ہیں، تو انفارمیشن سیکیورٹی چیک میں ایک دن لگے گا۔ کوئی بھی اس طرح عمل کو سست نہیں کرے گا۔ اس خصوصیت کو مدنظر رکھیں اور اپنے نتائج اخذ کریں۔
اعلی سطحی غلط منفی یا غلط مثبت۔ تمام مصنوعات مختلف ہیں، سبھی مختلف فریم ورک استعمال کرتے ہیں اور ان کا اپنا کوڈنگ اسٹائل ہے۔ مختلف کوڈ بیسز اور ٹیکنالوجیز پر، ٹولز غلط منفی اور غلط مثبت کی مختلف سطحیں دکھا سکتے ہیں۔ تو دیکھیں کہ اصل میں کیا ہے۔ آپ کمپنیوں اور کے لئے آپ ایپلی کیشنز اچھے اور قابل اعتماد نتائج دکھائے گی۔
موجودہ ٹولز کے ساتھ کوئی انضمام نہیں۔. جو آپ پہلے سے استعمال کرتے ہیں ان کے ساتھ انضمام کے نقطہ نظر سے ٹولز کو دیکھیں۔ مثال کے طور پر، اگر آپ کے پاس Jenkins یا TeamCity ہے، تو اس سافٹ ویئر کے ساتھ ٹولز کا انضمام چیک کریں، نہ کہ GitLab CI کے ساتھ، جسے آپ استعمال نہیں کرتے ہیں۔
تخصیص کی کمی یا ضرورت سے زیادہ پیچیدگی۔ اگر کسی ٹول میں API نہیں ہے تو پھر اس کی ضرورت کیوں ہے؟ ہر وہ چیز جو انٹرفیس میں کی جا سکتی ہے API کے ذریعے دستیاب ہونی چاہیے۔ مثالی طور پر، ٹول میں چیک کو اپنی مرضی کے مطابق کرنے کی صلاحیت ہونی چاہیے۔
کوئی پروڈکٹ ڈویلپمنٹ روڈ میپ نہیں۔ ترقی اب بھی کھڑی نہیں ہے، ہم ہمیشہ نئے فریم ورک اور فنکشنز کا استعمال کرتے ہیں، پرانے کوڈ کو نئی زبانوں میں دوبارہ لکھتے ہیں۔ ہم اس بات کو یقینی بنانا چاہتے ہیں کہ ہم جو ٹول خریدتے ہیں وہ نئے فریم ورک اور ٹیکنالوجیز کو سپورٹ کرے گا۔ لہذا، یہ جاننا ضروری ہے کہ مصنوعات کی اصل اور درست ہے ترقی
عمل کی خصوصیات
ٹولز کی خصوصیات کے علاوہ، ترقی کے عمل کی خصوصیات کو بھی مدنظر رکھیں۔ مثال کے طور پر ترقی کی راہ میں حائل ہونا ایک عام غلطی ہے۔ آئیے دیکھتے ہیں کہ دیگر کن خصوصیات کو مدنظر رکھنا چاہیے اور سیکیورٹی ٹیم کو کن چیزوں پر توجہ دینی چاہیے۔
ترقی سے محروم نہ ہونے اور ڈیڈ لائن جاری کرنے کے لیے، تخلیق کریں۔ مختلف قوانین اور مختلف روکنے والوں کو دکھائیں۔ - اگر کمزوریاں ہوں تو تعمیراتی عمل کو روکنے کا معیار - مختلف ماحول کے لیے. مثال کے طور پر، ہم سمجھتے ہیں کہ موجودہ برانچ ڈویلپمنٹ اسٹینڈ یا UAT پر جاتی ہے، جس کا مطلب ہے کہ ہم رک کر نہیں کہتے:
-آپ کے یہاں کمزوریاں ہیں، آپ مزید کہیں نہیں جائیں گے!
اس مرحلے پر، ڈویلپرز کو بتانا ضروری ہے کہ حفاظتی مسائل ہیں جن پر توجہ دینے کے قابل ہیں۔
کمزوریوں کی موجودگی مزید جانچ میں رکاوٹ نہیں ہے۔: دستی، انضمام یا دستی۔ دوسری طرف، ہمیں کسی نہ کسی طرح پروڈکٹ کی سیکیورٹی میں اضافہ کرنے کی ضرورت ہے، اور تاکہ ڈویلپرز کو یہ نہ بھولیں کہ وہ کیا محفوظ سمجھتے ہیں۔ اس لیے، بعض اوقات ہم یہ کرتے ہیں: اسٹینڈ پر، جب اسے ترقیاتی ماحول میں لایا جاتا ہے، تو ہم آسانی سے ترقی کو مطلع کرتے ہیں:
- دوستوں، آپ کو مسائل ہیں، براہ کرم ان پر توجہ دیں۔
UAT مرحلے پر ہم دوبارہ خطرات کے بارے میں انتباہات دکھاتے ہیں، اور ریلیز کے مرحلے پر ہم کہتے ہیں:
- دوستو، ہم نے آپ کو کئی بار خبردار کیا، آپ نے کچھ نہیں کیا - ہم آپ کو اس سے باہر نہیں ہونے دیں گے۔
اگر ہم کوڈ اور ڈائنامکس کے بارے میں بات کرتے ہیں، تو صرف ان خصوصیات اور کوڈ کی کمزوریوں کو ظاہر کرنا اور انتباہ کرنا ضروری ہے جو ابھی اس فیچر میں لکھے گئے تھے۔ اگر کوئی ڈویلپر بٹن کو 3 پکسلز بڑھاتا ہے اور ہم اسے کہتے ہیں کہ اس کے پاس وہاں ایس کیو ایل انجکشن ہے اور اس لیے اسے فوری طور پر ٹھیک کرنے کی ضرورت ہے، تو یہ غلط ہے۔ صرف اس پر نظر ڈالیں جو ابھی لکھا گیا ہے اور درخواست میں آنے والی تبدیلیوں کو دیکھیں۔
ہم کہتے ہیں کہ ہمارے پاس ایک خاص فنکشنل خرابی ہے - جس طرح سے ایپلی کیشن کو کام نہیں کرنا چاہئے: رقم منتقل نہیں ہوتی ہے، جب آپ بٹن پر کلک کرتے ہیں تو اگلے صفحے پر کوئی منتقلی نہیں ہوتی ہے، یا پروڈکٹ لوڈ نہیں ہوتی ہے۔ حفاظتی نقائص - یہ وہی نقائص ہیں، لیکن ایپلیکیشن آپریشن کے لحاظ سے نہیں، بلکہ سیکورٹی میں۔
تمام سافٹ ویئر کے معیار کے مسائل سیکورٹی کے مسائل نہیں ہیں. لیکن سیکیورٹی کے تمام مسائل سافٹ ویئر کے معیار سے متعلق ہیں۔ شریف منصور، ایکسپیڈیا۔
چونکہ تمام کمزوریاں نقائص ہیں، اس لیے انہیں اسی جگہ پر ہونا چاہیے جہاں تمام ترقیاتی نقائص ہیں۔ لہذا ایسی رپورٹس اور خوفناک پی ڈی ایف کو بھول جائیں جنہیں کوئی نہیں پڑھتا۔
جب میں ایک ڈویلپمنٹ کمپنی میں کام کر رہا تھا، مجھے سٹیٹک اینالائسز ٹولز سے ایک رپورٹ موصول ہوئی۔ میں نے اسے کھولا، گھبرا گیا، کافی بنائی، 350 صفحات پلٹائے، اسے بند کیا اور کام پر چلا گیا۔ بڑی رپورٹیں ڈیڈ رپورٹس ہیں۔. عام طور پر وہ کہیں نہیں جاتے، ای میلز حذف ہو جاتی ہیں، بھول جاتی ہیں، گم ہو جاتی ہیں، یا کاروبار کہتا ہے کہ یہ خطرہ مول لے رہا ہے۔
کیا کرنا ہے؟ ہم صرف ان تصدیق شدہ نقائص کو تبدیل کرتے ہیں جو ہمیں ترقی کے لیے آسان شکل میں ملتے ہیں، مثال کے طور پر، ہم انہیں جیرا میں بیک لاگ میں ڈال دیتے ہیں۔ ہم نقائص کو ترجیح دیتے ہیں اور انہیں اسی ترتیب سے ختم کرتے ہیں جس طرح فنکشنل نقائص اور ٹیسٹ کے نقائص۔
جامد تجزیہ - SAST
یہ کمزوریوں کی موجودگی کے لیے کوڈ کا تجزیہ ہے۔، لیکن یہ سونار کیوب جیسا نہیں ہے۔ ہم صرف پیٹرن یا انداز کی جانچ نہیں کرتے۔ تجزیہ میں کئی طریقوں کا استعمال کیا جاتا ہے: خطرے کے درخت کے مطابق، کے مطابق ، کنفیگریشن فائلوں کا تجزیہ کرکے۔ یہ وہ سب ہے جو خود کوڈ سے متعلق ہے۔
نقطہ نظر کے فوائد: ترقی کے ابتدائی مرحلے میں کوڈ میں کمزوریوں کی نشاندہی کرناجب ابھی تک کوئی اسٹینڈ یا ریڈی میڈ ٹول نہ ہوں، اور بڑھتی ہوئی سکیننگ کی صلاحیت: کوڈ کے ایک حصے کو اسکین کرنا جو بدل گیا ہے اور صرف وہی خصوصیت جو ہم فی الحال کر رہے ہیں، جس سے اسکیننگ کا وقت کم ہوجاتا ہے۔
Cons - یہ ضروری زبانوں کی حمایت کی کمی ہے۔
ضروری انضمام، جو ٹولز میں ہونا چاہیے، میری ساپیکش رائے میں:
- انٹیگریشن ٹول: جینکنز، ٹیم سٹی اور گٹلاب سی آئی۔
- ترقیاتی ماحول: انٹیلیج IDEA، بصری اسٹوڈیو۔ ایک ڈویلپر کے لیے یہ زیادہ آسان ہے کہ وہ کسی ناقابل فہم انٹرفیس پر تشریف نہ لائے جسے ابھی بھی یاد رکھنے کی ضرورت ہے، بلکہ ان تمام ضروری انضمام اور کمزوریوں کو دیکھنا ہے جو اس نے اپنے کام کی جگہ پر اپنے ترقیاتی ماحول میں پائی ہیں۔
- کوڈ کا جائزہ: سونار کیوب اور دستی جائزہ۔
- ڈیفیکٹ ٹریکرز: جیرا اور بگزیلا۔
تصویر جامد تجزیہ کے بہترین نمائندوں میں سے کچھ دکھاتا ہے.
یہ وہ اوزار نہیں ہیں جو اہم ہیں، بلکہ عمل ہے، اس لیے وہاں اوپن سورس حل موجود ہیں جو عمل کی جانچ کے لیے بھی اچھے ہیں۔
SAST اوپن سورس کو بڑی تعداد میں کمزوریاں یا پیچیدہ ڈیٹا فلوز نہیں ملیں گے، لیکن وہ عمل کو بناتے وقت استعمال کر سکتے ہیں اور ہونا چاہیے۔ وہ آپ کو یہ سمجھنے میں مدد کرتے ہیں کہ عمل کیسے بنایا جائے گا، کون کیڑے کا جواب دے گا، کون رپورٹ کرے گا، کون رپورٹ کرے گا۔ اگر آپ اپنے کوڈ کی سیکیورٹی بنانے کے ابتدائی مرحلے کو انجام دینا چاہتے ہیں تو اوپن سورس حل استعمال کریں۔
اگر آپ اپنے سفر کے آغاز میں ہیں اور آپ کے پاس کچھ نہیں ہے تو اسے کیسے مربوط کیا جا سکتا ہے: نہ CI، نہ جینکنز، نہ ٹیم سٹی؟ آئیے عمل میں انضمام کو دیکھیں۔
CVS سطح پر انضمام
اگر آپ کے پاس Bitbucket یا GitLab ہے، تو آپ ضم کر سکتے ہیں۔ .
واقعہ سے - کھینچنے کی درخواست، کمٹ۔ آپ کوڈ کو اسکین کریں اور بلڈ اسٹیٹس میں دکھائیں کہ آیا سیکیورٹی چیک پاس ہوا یا ناکام۔
تاثرات یقینا، رائے ہمیشہ کی ضرورت ہے. اگر آپ نے صرف سیکورٹی سائیڈ پر سیکیورٹی کی ہے، اسے ایک ڈبے میں ڈال دیا ہے اور اس کے بارے میں کسی کو کچھ نہیں بتایا، اور پھر مہینے کے آخر میں کیڑے کا ایک گروپ پھینک دیا، یہ درست نہیں ہے اور اچھا نہیں ہے۔
کوڈ ریویو سسٹم کے ساتھ انضمام
ایک بار، ہم نے متعدد اہم پروجیکٹس میں ایک AppSec تکنیکی صارف کے لیے ڈیفالٹ جائزہ کار کے طور پر کام کیا۔ اس بات پر منحصر ہے کہ آیا نئے کوڈ میں غلطیوں کی نشاندہی کی گئی ہے یا کوئی خرابی نہیں ہے، جائزہ لینے والا پل کی درخواست پر "قبول" یا "کام کی ضرورت ہے" کے لیے اسٹیٹس سیٹ کرتا ہے - یا تو سب کچھ ٹھیک ہے، یا اسے بہتر کرنے کی ضرورت ہے اور کن چیزوں سے لنک کرنا ہے۔ بالکل بہتر کرنے کی ضرورت ہے. اس ورژن کے ساتھ انضمام کے لیے جو پروڈکشن میں جا رہا ہے، ہم نے انفارمیشن سیکیورٹی ٹیسٹ پاس نہ ہونے کی صورت میں انضمام کی ممانعت کو فعال کر دیا ہے۔ ہم نے اسے دستی کوڈ کے جائزے میں شامل کیا، اور باقی عمل کے شرکاء نے اس مخصوص عمل کے لیے حفاظتی حالات دیکھے۔
سونار کیوب کے ساتھ انضمام
بہت سے لوگوں کے پاس ہے۔ کوڈ کے معیار کے مطابق۔ یہاں بھی ایسا ہی ہے - آپ وہی گیٹس صرف SAST ٹولز کے لیے کر سکتے ہیں۔ ایک ہی انٹرفیس ہوگا، ایک ہی کوالٹی گیٹ ہوگا، صرف اسے کہا جائے گا۔ سیکورٹی گیٹ. اور اسی طرح، اگر آپ کے پاس سونار کیوب استعمال کرنے کا عمل ہے، تو آپ وہاں ہر چیز کو آسانی سے ضم کر سکتے ہیں۔
CI سطح پر انضمام
یہاں سب کچھ بہت آسان ہے:
- آٹوٹیسٹ کے طور پر ایک ہی سطح پر، یونٹ ٹیسٹ۔
- ترقی کے مراحل کے لحاظ سے تقسیم: دیو، ٹیسٹ، پیداوار۔ قواعد کے مختلف سیٹ یا مختلف ناکام حالات شامل کیے جا سکتے ہیں: اسمبلی کو روکیں، اسمبلی کو مت روکیں۔
- ہم وقت ساز/اسینکرونس لانچ. ہم حفاظتی امتحانات کے اختتام کا انتظار کر رہے ہیں یا نہیں۔ یعنی ہم نے صرف انہیں لانچ کیا اور آگے بڑھتے ہیں اور پھر ہمیں یہ درجہ مل جاتا ہے کہ ہر چیز اچھی ہے یا بری۔
یہ سب ایک بہترین گلابی دنیا میں ہے۔ حقیقی زندگی میں ایسا کچھ نہیں ہے، لیکن ہم اس کے لیے کوشش کرتے ہیں۔ سیکیورٹی چیک چلانے کا نتیجہ یونٹ ٹیسٹ کے نتائج سے ملتا جلتا ہونا چاہیے۔
مثال کے طور پر، ہم نے ایک بڑا پروجیکٹ لیا اور فیصلہ کیا کہ اب ہم اسے SAST - OK کے ساتھ اسکین کریں گے۔ ہم نے اس پروجیکٹ کو SAST میں دھکیل دیا، اس نے ہمیں 20 خطرات کا سامنا کرنا پڑا اور ایک مضبوط ارادے کے فیصلے سے ہم نے فیصلہ کیا کہ سب کچھ ٹھیک ہے۔ 000 کمزوریاں ہمارا تکنیکی قرض ہے۔ ہم قرض کو ایک باکس میں ڈالیں گے، ہم اسے آہستہ آہستہ صاف کریں گے اور خرابی کے ٹریکرز میں کیڑے شامل کریں گے۔ آئیے ایک کمپنی کی خدمات حاصل کریں، سب کچھ خود کریں، یا سیکیورٹی چیمپئنز سے ہماری مدد کریں - اور تکنیکی قرض کم ہو جائے گا۔
اور نئے کوڈ میں نئی ابھرتی ہوئی تمام کمزوریوں کو اسی طرح ختم کیا جانا چاہیے جس طرح کسی یونٹ یا آٹو ٹیسٹس میں خرابیاں ہوتی ہیں۔ نسبتاً، اسمبلی شروع ہوئی، ہم نے اسے چلایا، دو ٹیسٹ اور دو سیکیورٹی ٹیسٹ ناکام ہوئے۔ ٹھیک ہے - ہم گئے، جو ہوا اسے دیکھا، ایک چیز ٹھیک کی، دوسری ٹھیک کی، اگلی بار چلائی - سب کچھ ٹھیک ہے، کوئی نئی کمزوری ظاہر نہیں ہوئی، کوئی ٹیسٹ ناکام نہیں ہوا۔ اگر یہ کام گہرا ہے اور آپ کو اسے اچھی طرح سے سمجھنے کی ضرورت ہے، یا کمزوریوں کو ٹھیک کرنا اس کی بڑی تہوں کو متاثر کرتا ہے جو ہڈ کے نیچے ہے: خرابی ٹریکر میں ایک بگ شامل کیا گیا تھا، اسے ترجیح دی جاتی ہے اور اسے درست کیا جاتا ہے۔ بدقسمتی سے، دنیا مثالی نہیں ہے اور بعض اوقات امتحانات ناکام ہو جاتے ہیں۔
سیکیورٹی گیٹ کی ایک مثال کوالٹی گیٹ کا ینالاگ ہے، کوڈ میں موجود خطرات اور ان کی تعداد کے لحاظ سے۔
ہم سونار کیوب کے ساتھ مربوط ہیں - پلگ ان انسٹال ہے، سب کچھ بہت آسان اور ٹھنڈا ہے۔
ترقیاتی ماحول کے ساتھ انضمام
انضمام کے اختیارات:
- ارتکاب کرنے سے پہلے ترقیاتی ماحول سے اسکین شروع کرنا۔
- نتائج دیکھیں۔
- نتائج کا تجزیہ۔
- سرور کے ساتھ ہم آہنگی۔
سرور سے نتائج حاصل کرنا ایسا ہی لگتا ہے۔
ہمارے ترقیاتی ماحول میں ایک اضافی آئٹم آسانی سے ظاہر ہوتا ہے جو آپ کو مطلع کرتا ہے کہ سکیننگ کے دوران اس طرح کی کمزوریوں کا پتہ چلا ہے۔ آپ فوری طور پر کوڈ میں ترمیم کر سکتے ہیں، سفارشات کو دیکھ سکتے ہیں اور . یہ سب ڈویلپر کے کام کی جگہ پر واقع ہے، جو بہت آسان ہے - آپ کو دوسرے لنکس کی پیروی کرنے اور کسی بھی اضافی چیز کو دیکھنے کی ضرورت نہیں ہے۔
کھلا ماخذ
یہ میرا پسندیدہ موضوع ہے۔ ہر کوئی اوپن سورس لائبریریوں کا استعمال کرتا ہے - بیساکھیوں اور سائیکلوں کا ایک گچھا کیوں لکھیں جب آپ ایک ریڈی میڈ لائبریری لے سکتے ہیں جس میں سب کچھ پہلے سے نافذ ہے؟
بلاشبہ، یہ سچ ہے، لیکن لائبریریاں بھی لوگوں کی طرف سے لکھی جاتی ہیں، ان میں بعض خطرات بھی شامل ہوتے ہیں، اور ایسے خطرات بھی ہوتے ہیں جو وقتاً فوقتاً، یا مسلسل رپورٹ کیے جاتے ہیں۔ لہذا، ایپلی کیشن سیکیورٹی میں ایک اگلا مرحلہ ہے - یہ اوپن سورس اجزاء کا تجزیہ ہے۔
اوپن سورس تجزیہ - OSA
ٹول میں تین بڑے مراحل شامل ہیں۔
لائبریریوں میں کمزوریوں کی تلاش۔ مثال کے طور پر، ٹول جانتا ہے کہ ہم کچھ لائبریری استعمال کر رہے ہیں، اور وہ یا بگ ٹریکرز میں کچھ کمزوریاں ہیں جو لائبریری کے اس ورژن سے متعلق ہیں۔ جب آپ اسے استعمال کرنے کی کوشش کریں گے، تو ٹول ایک انتباہ جاری کرے گا کہ لائبریری کمزور ہے اور آپ کو مشورہ دیتا ہے کہ کوئی دوسرا ورژن استعمال کریں جس میں خطرات نہ ہوں۔
لائسنس کی پاکیزگی کا تجزیہ۔ یہ ابھی تک یہاں خاص طور پر مقبول نہیں ہے، لیکن اگر آپ بیرون ملک کام کرتے ہیں، تو آپ وقتاً فوقتاً وہاں ایک اوپن سورس جزو استعمال کرنے کے لیے فیس وصول کر سکتے ہیں جسے استعمال یا تبدیل نہیں کیا جا سکتا۔ لائسنس یافتہ لائبریری کی پالیسی کے مطابق، ہم ایسا نہیں کر سکتے۔ یا، اگر ہم اس میں ترمیم کرکے اسے استعمال کرتے ہیں، تو ہمیں اپنا کوڈ پوسٹ کرنا چاہیے۔ بے شک، کوئی بھی اپنی مصنوعات کا کوڈ شائع نہیں کرنا چاہتا، لیکن آپ اس سے اپنے آپ کو بھی بچا سکتے ہیں۔
ان اجزاء کا تجزیہ جو صنعتی ماحول میں استعمال ہوتے ہیں۔ آئیے ایک فرضی صورت حال کا تصور کریں: ہم نے آخر کار ترقی مکمل کر لی ہے اور اپنی مائیکرو سروس کی تازہ ترین ریلیز جاری کر دی ہے۔ وہ وہاں حیرت انگیز طور پر رہتا ہے - ایک ہفتہ، ایک مہینہ، ایک سال۔ ہم اسے جمع نہیں کرتے، ہم حفاظتی چیک نہیں کرتے، لگتا ہے سب کچھ ٹھیک ہے۔ لیکن اچانک، ریلیز کے دو ہفتے بعد، اوپن سورس جزو میں ایک اہم کمزوری ظاہر ہوتی ہے، جسے ہم صنعتی ماحول میں اس مخصوص تعمیر میں استعمال کرتے ہیں۔ اگر ہم یہ ریکارڈ نہیں کرتے ہیں کہ ہم اسے کیا اور کہاں استعمال کرتے ہیں، تو ہمیں یہ خطرہ نظر نہیں آئے گا۔ کچھ ٹولز لائبریریوں میں موجود کمزوریوں کی نگرانی کرنے کی صلاحیت رکھتے ہیں جو فی الحال انڈسٹری میں استعمال ہوتی ہیں۔ یہ بہت مفید ہے۔
مواقع:
- ترقی کے مختلف مراحل کے لیے مختلف پالیسیاں۔
- صنعتی ماحول میں اجزاء کی نگرانی۔
- تنظیم کے اندر لائبریریوں کا کنٹرول۔
- مختلف تعمیراتی نظاموں اور زبانوں کے لیے سپورٹ۔
- ڈوکر امیجز کا تجزیہ۔
صنعت کے رہنماؤں کی چند مثالیں جو اوپن سورس تجزیہ میں مصروف ہیں۔
واحد مفت ہے۔ OWASP سے آپ اسے پہلے مرحلے پر آن کر سکتے ہیں، دیکھیں کہ یہ کیسے کام کرتا ہے اور کس چیز کو سپورٹ کرتا ہے۔ بنیادی طور پر، یہ تمام کلاؤڈ پروڈکٹس ہیں، یا آن پریمیس، لیکن ان کی بنیاد کے پیچھے وہ اب بھی انٹرنیٹ پر بھیجے جاتے ہیں۔ وہ آپ کی لائبریریوں کو نہیں، بلکہ ہیشز یا اپنی اقدار بھیجتے ہیں، جن کا وہ حساب لگاتے ہیں، اور خطرات کی موجودگی کے بارے میں معلومات حاصل کرنے کے لیے اپنے سرور پر فنگر پرنٹس بھیجتے ہیں۔
عمل میں انضمام
دائرہ کار میں لائبریریوں کا کنٹرول، جو بیرونی ذرائع سے ڈاؤن لوڈ کیے گئے ہیں۔ ہمارے پاس بیرونی اور اندرونی ذخیرے ہیں۔ مثال کے طور پر، Event Central Nexus چلاتا ہے، اور ہم چاہتے ہیں کہ ہمارے ذخیرے میں "تنقیدی" یا "اعلی" حیثیت کے ساتھ کوئی کمزوری نہ ہو۔ آپ Nexus Firewall Lifecycle ٹول کا استعمال کرتے ہوئے پراکسینگ کو کنفیگر کر سکتے ہیں تاکہ ایسی کمزوریاں منقطع ہو جائیں اور اندرونی ذخیرہ میں ختم نہ ہوں۔
CI میں انضمام. آٹو ٹیسٹس، یونٹ ٹیسٹ اور ترقی کے مراحل میں تقسیم کے ساتھ ایک ہی سطح پر: دیو، ٹیسٹ، پروڈ۔ ہر مرحلے پر، آپ کسی بھی لائبریری کو ڈاؤن لوڈ کر سکتے ہیں، کچھ بھی استعمال کر سکتے ہیں، لیکن اگر "تنقیدی" حیثیت کے ساتھ کچھ مشکل ہے، تو یہ صنعت میں ریلیز کے مرحلے پر ڈویلپرز کی توجہ میں لانے کے قابل ہو سکتا ہے۔
نوادرات کے ساتھ انضمام: Nexus اور JFrog۔
ترقیاتی ماحول میں انضمام۔ آپ کے منتخب کردہ ٹولز کا ترقیاتی ماحول کے ساتھ انضمام ہونا چاہیے۔ ڈویلپر کو اپنے کام کی جگہ سے اسکیننگ کے نتائج تک رسائی حاصل ہونی چاہیے، یا CVS کا ارتکاب کرنے سے پہلے کمزوریوں کے لیے کوڈ کو اسکین کرنے اور چیک کرنے کی اہلیت ہونی چاہیے۔
سی ڈی میں انضمام۔ یہ ایک عمدہ خصوصیت ہے جو مجھے واقعی پسند ہے اور جس کے بارے میں میں پہلے ہی بات کر چکا ہوں - صنعتی ماحول میں نئی کمزوریوں کے ظہور کی نگرانی۔ یہ کچھ اس طرح کام کرتا ہے۔
ہمارے پاس ہے۔ عوامی اجزاء کے ذخیرے - باہر کے کچھ ٹولز، اور ہمارا اندرونی ذخیرہ۔ ہم چاہتے ہیں کہ اس میں صرف قابل اعتماد اجزاء شامل ہوں۔ درخواست پراکسی کرتے وقت، ہم چیک کرتے ہیں کہ ڈاؤن لوڈ کی گئی لائبریری میں کمزوریاں نہیں ہیں۔ اگر یہ کچھ پالیسیوں کے تحت آتا ہے جو ہم قائم کرتے ہیں اور ضروری طور پر ترقی کے ساتھ ہم آہنگی کرتے ہیں، تو ہم اسے ڈاؤن لوڈ نہیں کرتے ہیں اور دوسرا ورژن استعمال کرنے پر مجبور ہوتے ہیں۔ اس کے مطابق، اگر لائبریری میں واقعی کوئی نازک اور خراب چیز ہے، تو ڈیولپر کو انسٹالیشن کے مرحلے پر لائبریری موصول نہیں ہوگی - اسے اعلی یا کم ورژن استعمال کرنے دیں۔
- تعمیر کرتے وقت، ہم چیک کرتے ہیں کہ کسی نے کوئی چیز خراب تو نہیں کی، تمام اجزاء محفوظ ہیں اور کوئی بھی فلیش ڈرائیو پر کوئی خطرناک چیز نہیں لایا ہے۔
- مخزن میں ہمارے پاس صرف قابل اعتماد اجزاء ہیں۔
- تعینات کرتے وقت، ہم ایک بار پھر پیکج کو خود چیک کرتے ہیں: جنگ، جار، ڈی ایل یا ڈوکر امیج کو یقینی بنانے کے لیے کہ یہ پالیسی کی تعمیل کرتا ہے۔
- صنعت میں داخل ہونے پر، ہم نگرانی کرتے ہیں کہ صنعتی ماحول میں کیا ہو رہا ہے: اہم کمزوریاں ظاہر ہوتی ہیں یا ظاہر نہیں ہوتیں۔
متحرک تجزیہ - DAST
متحرک تجزیہ کے اوزار بنیادی طور پر اب تک کہی گئی ہر چیز سے مختلف ہیں۔ یہ ایپلیکیشن کے ساتھ صارف کے کام کی ایک طرح کی تقلید ہے۔ اگر یہ ویب ایپلیکیشن ہے تو ہم کلائنٹ کے کام کی نقل کرتے ہوئے درخواستیں بھیجتے ہیں، سامنے والے بٹنوں پر کلک کرتے ہیں، فارم سے مصنوعی ڈیٹا بھیجتے ہیں: کوٹس، بریکٹ، مختلف انکوڈنگز میں حروف، یہ دیکھنے کے لیے کہ ایپلی کیشن کیسے کام کرتی ہے اور بیرونی ڈیٹا پر کارروائی کرتا ہے۔
یہی نظام آپ کو اوپن سورس میں ٹیمپلیٹ کی کمزوریوں کو چیک کرنے کی اجازت دیتا ہے۔ چونکہ DAST نہیں جانتا کہ ہم کون سا اوپن سورس استعمال کر رہے ہیں، اس لیے یہ صرف "بدنتی پر مبنی" پیٹرن پھینکتا ہے اور سرور کے جوابات کا تجزیہ کرتا ہے:
- ہاں، یہاں ڈی سیریلائزیشن کا مسئلہ ہے، لیکن یہاں نہیں۔
اس میں بڑے خطرات ہیں، کیونکہ اگر آپ اس سیکیورٹی ٹیسٹ کو اسی بینچ پر کراتے ہیں جس کے ساتھ ٹیسٹرز کام کرتے ہیں تو بری چیزیں ہوسکتی ہیں۔
- ایپلیکیشن نیٹ ورک سرور پر زیادہ بوجھ۔
- کوئی انضمام نہیں۔
- تجزیہ کردہ درخواست کی ترتیبات کو تبدیل کرنے کی صلاحیت۔
- ضروری ٹیکنالوجیز کے لیے کوئی سپورٹ نہیں ہے۔
- ترتیب دینے میں دشواری۔
ہمارے پاس ایسی صورت حال تھی جب ہم نے بالآخر AppScan لانچ کیا: ہم ایک طویل عرصے سے ایپلیکیشن تک رسائی حاصل کرنے کی کوشش کر رہے تھے، 3 اکاؤنٹس ملے اور خوش تھے - ہم آخر کار سب کچھ چیک کر لیں گے! ہم نے اسکین کرنا شروع کر دیا، اور سب سے پہلے AppScan نے ایڈمن پینل میں جانا، تمام بٹنوں کو چھیدنا، آدھا ڈیٹا تبدیل کرنا، اور پھر سرور کو خود ہی مکمل طور پر ختم کر دیا۔ - درخواستیں جانچ کے ساتھ ترقی نے کہا:
- دوستو، کیا تم مجھ سے مذاق کر رہے ہو؟! ہم نے آپ کو اکاؤنٹس دیئے، اور آپ نے ایک موقف قائم کیا!
ممکنہ خطرات پر غور کریں۔ مثالی طور پر، انفارمیشن سیکیورٹی کی جانچ کے لیے ایک الگ اسٹینڈ تیار کریں، جو کم از کم کسی نہ کسی طرح باقی ماحول سے الگ ہو جائے گا، اور ایڈمن پینل کو چیک کریں، ترجیحا دستی موڈ میں۔ یہ ایک پینٹسٹ ہے - کوشش کے وہ باقی فیصد جن پر ہم فی الحال غور نہیں کر رہے ہیں۔
یہ قابل غور ہے کہ آپ اسے لوڈ ٹیسٹنگ کے ینالاگ کے طور پر استعمال کر سکتے ہیں۔ پہلے مرحلے پر، آپ 10-15 دھاگوں میں ایک متحرک اسکینر کو آن کر سکتے ہیں اور دیکھ سکتے ہیں کہ کیا ہوتا ہے، لیکن عام طور پر، جیسا کہ پریکٹس سے ظاہر ہوتا ہے، کچھ بھی اچھا نہیں ہوتا۔
چند وسائل جو ہم عام طور پر استعمال کرتے ہیں۔
نمایاں کرنے کے قابل کسی بھی سیکورٹی پروفیشنل کے لیے ایک "سوئس چاقو" ہے۔ ہر کوئی اسے استعمال کرتا ہے اور یہ بہت آسان ہے۔ انٹرپرائز ایڈیشن کا ایک نیا ڈیمو ورژن اب جاری کیا گیا ہے۔ اگر پہلے یہ پلگ ان کے ساتھ صرف اسٹینڈ اکیلے یوٹیلیٹی تھی، اب ڈویلپرز آخر کار ایک بڑا سرور بنا رہے ہیں جس سے کئی ایجنٹوں کا انتظام کرنا ممکن ہوگا۔ یہ اچھا ہے، میں تجویز کرتا ہوں کہ آپ اسے آزمائیں۔
عمل میں انضمام
انضمام بہت اچھی طرح سے ہوتا ہے اور آسان ہے: کامیاب تنصیب کے بعد اسکیننگ شروع کریں۔ موقف کے لیے درخواستیں اور کامیاب انضمام کی جانچ کے بعد اسکیننگ.
اگر انضمام کام نہیں کرتے ہیں یا اسٹبس اور فرضی فنکشنز ہیں، تو یہ بے معنی اور بیکار ہے - اس سے کوئی فرق نہیں پڑتا ہے کہ ہم جو بھی نمونہ بھیجیں، سرور اب بھی اسی طرح جواب دے گا۔
- مثالی طور پر، ایک الگ ٹیسٹنگ اسٹینڈ۔
- جانچ کرنے سے پہلے، لاگ ان کی ترتیب لکھیں۔
- انتظامی نظام کی جانچ صرف دستی ہے۔
عمل
عام طور پر عمل کے بارے میں اور خاص طور پر ہر آلے کے کام کے بارے میں تھوڑا سا عام کرنا۔ تمام ایپلی کیشنز مختلف ہیں - کچھ متحرک تجزیہ کے ساتھ بہتر کام کرتی ہیں، دیگر جامد تجزیہ کے ساتھ، دیگر اوپن سورس تجزیہ کے ساتھ، پینٹسٹس، یا مکمل طور پر کچھ اور، مثال کے طور پر، واقعات کے ساتھ .
ہر عمل کو کنٹرول کی ضرورت ہوتی ہے۔
یہ سمجھنے کے لیے کہ کوئی عمل کیسے کام کرتا ہے اور اسے کہاں بہتر کیا جا سکتا ہے، آپ کو ہر اس چیز سے میٹرکس اکٹھا کرنے کی ضرورت ہے جس پر آپ اپنے ہاتھ حاصل کر سکتے ہیں، بشمول پروڈکشن میٹرکس، ٹولز سے میٹرکس، اور خراب ٹریکرز سے۔
کوئی بھی معلومات مددگار ہے۔ آپ کو مختلف نقطہ نظر سے دیکھنے کی ضرورت ہے کہ جہاں ایک یا دوسرا ٹول بہتر طور پر استعمال ہوتا ہے، جہاں عمل خاص طور پر گھٹ جاتا ہے۔ وقت کی بنیاد پر عمل کو کہاں بہتر کرنا ہے یہ سمجھنے کے لیے ترقی کے ردعمل کے وقت کو دیکھنے کے قابل ہو سکتا ہے۔ جتنا زیادہ ڈیٹا، ہر عمل کی تفصیلات تک اعلیٰ سطح سے زیادہ حصے بنائے جا سکتے ہیں۔
چونکہ تمام جامد اور متحرک تجزیہ کاروں کے اپنے APIs ہیں، ان کے اپنے لانچ کے طریقے، اصول ہیں، کچھ کے پاس شیڈیولر ہیں، دوسروں کے پاس نہیں ہے - ہم ایک ٹول لکھ رہے ہیں AppSec آرکیسٹریٹر، جو آپ کو پروڈکٹ سے پورے عمل میں ایک واحد انٹری پوائنٹ بنانے اور اسے ایک نقطہ سے منظم کرنے کی اجازت دیتا ہے۔
مینیجرز، ڈویلپرز اور سیکیورٹی انجینئرز کے پاس ایک انٹری پوائنٹ ہوتا ہے جہاں سے وہ دیکھ سکتے ہیں کہ کیا چل رہا ہے، اسکین ترتیب دے سکتے ہیں اور اسے چلا سکتے ہیں، اسکین کے نتائج حاصل کرسکتے ہیں، اور ضروریات جمع کر سکتے ہیں۔ ہم کاغذی کارروائی سے دور جانے کی کوشش کرتے ہیں، ہر چیز کا انسانی زبان میں ترجمہ کرنے کی کوشش کرتے ہیں، جسے ترقی کے ذریعے استعمال کیا جاتا ہے - اسٹیٹس اور میٹرکس کے ساتھ سنگم پر صفحات، جیرا میں نقائص یا مختلف ڈیفیکٹ ٹریکرز میں، یا CI/CD میں ایک ہم وقت ساز/غیر مطابقت پذیر عمل میں انضمام۔
کلیدی لے لو
اوزار سب سے اہم چیز نہیں ہیں۔ پہلے عمل کے بارے میں سوچیں - پھر ٹولز کو لاگو کریں۔ ٹولز اچھے لیکن مہنگے ہیں، لہذا آپ اس عمل کے ساتھ شروع کر سکتے ہیں اور ترقی اور سلامتی کے درمیان مواصلات اور افہام و تفہیم پیدا کر سکتے ہیں۔ حفاظتی نقطہ نظر سے، ہر چیز کو "روکنے" کی ضرورت نہیں ہے۔ ترقی کے نقطہ نظر سے، اگر کوئی اعلیٰ ترین میگا سپر کریٹیکل ہے، تو اسے ختم کرنے کی ضرورت ہے، اور اس مسئلے پر آنکھیں بند کرنے کی ضرورت نہیں ہے۔
مصنوعات کا معیار - عام مقصد سیکورٹی اور ترقی دونوں. ہم ایک کام کرتے ہیں، ہم اس بات کو یقینی بنانے کی کوشش کرتے ہیں کہ ہر چیز صحیح طریقے سے کام کرے اور کوئی ساکھ کے خطرات یا مالی نقصانات نہ ہوں۔ اسی لیے ہم مواصلات کو بہتر بنانے اور ایک بہتر پروڈکٹ بنانے کے لیے DevSecOps, SecDevOps اپروچ کو فروغ دیتے ہیں۔
جو آپ کے پاس پہلے سے ہے اس سے شروع کریں۔: ضروریات، فن تعمیر، جزوی جانچ، تربیت، رہنما خطوط۔ تمام منصوبوں پر فوری طور پر تمام طریقوں کو لاگو کرنے کی ضرورت نہیں ہے۔ تکراری طور پر منتقل کریں. کوئی ایک معیار نہیں ہے - تجربہ اور مختلف طریقوں اور حلوں کی کوشش کریں۔
معلومات کی حفاظت کے نقائص اور فنکشنل نقائص کے درمیان مساوی علامت ہے۔.
ہر چیز کو خودکار بنائیںکہ چلتا ہے. ہر چیز کو منتقل اور خودکار کریں جو حرکت نہیں کرتی ہے۔ اگر کچھ ہاتھ سے کیا جاتا ہے، تو یہ عمل کا اچھا حصہ نہیں ہے۔ شاید یہ اس کا جائزہ لینے اور اسے خودکار کرنے کے قابل ہے۔
اگر IS ٹیم کا سائز چھوٹا ہے، سیکیورٹی چیمپئنز کا استعمال کریں۔.
شاید میں نے جس کے بارے میں بات کی ہے وہ آپ کے مطابق نہیں ہوگی اور آپ خود ہی کچھ لے کر آئیں گے - اور یہ اچھا ہے۔ لیکن اپنے عمل کی ضروریات کی بنیاد پر ٹولز کا انتخاب کریں۔. یہ مت دیکھو کہ کمیونٹی کیا کہتی ہے کہ یہ ٹول برا ہے اور یہ اچھا ہے۔ شاید اس کے برعکس آپ کی مصنوعات کے لئے سچ ہو جائے گا.
اوزار کے لیے تقاضے
- نچلی سطح کا جھوٹا مثبت۔
- مناسب تجزیہ کا وقت۔
- استعمال میں آسانی
- انضمام کی دستیابی
- مصنوعات کی ترقی کے روڈ میپ کو سمجھنا۔
- حسب ضرورت ٹولز کا امکان۔
DevOpsConf 2018 میں یوری کی رپورٹ کو بہترین میں سے ایک کے طور پر منتخب کیا گیا۔ مزید دلچسپ خیالات اور عملی صورتوں سے واقف ہونے کے لیے، 27 اور 28 مئی کو Skolkovo آئیں کے اندر . بہتر ابھی تک، اگر آپ اپنا تجربہ شیئر کرنے کے لیے تیار ہیں، تو 21 اپریل تک رپورٹ کے لیے۔
ماخذ: www.habr.com