ایک سیکیورٹی پروگرام صفر سے بنانا

کسی کمپنی میں پہلے سیکیورٹی شخص کے طور پر نوکری ملنا ایک خاص قسم کی خرابی ہے۔ کوئی ٹکٹ قیو نہیں ہے، کوئی قائم شدہ ٹولنگ نہیں، اور عام طور پر آپ کے لیے کوئی بجٹ لائن انتظار میں نہیں ہے۔ جو آگے آتا ہے وہ اس بات کا ایک تقریبی نقشہ ہے کہ وہ پہلے 90-180 دن عام طور پر کیسے گزرتے ہیں، اور اصل میں کیا سوئی حرکت کرتا ہے بمقابلہ جو صرف پروڈکٹو لگتا ہے۔

"کچھ نہیں" عام طور پر کیا مطلب ہے

جب لوگ کہتے ہیں کہ کسی کمپنی کے پاس کوئی سیکیورٹی فنکشن نہیں ہے، تو وہ شاذ و نادر ہی صفر کنٹرول کا مطلب رکھتے ہیں۔ ان کا مطلب ہے کوئی مخصوص مالک نہیں۔ انجینیئرنگ نے شاید کچھ بنیادی AWS IAM پالیسیاں فعال کی ہیں، IT کے پاس کچھ antivirus MDM ٹول کے ذریعے رول آؤٹ ہے، اور finance میں کسی کے پاس SOC 2 کے بارے میں رائے ہے کیونکہ کسی customer نے پوچھا۔ آپ کا پہلا کام implementation نہیں بلکہ inventory ہے۔ ایک بھی پالیسی لکھنے سے پہلے، دیکھو کہ کیا پہلے سے چل رہا ہے: کلاؤڈ اکاؤنٹس (اور کتنے کہ کوئی یاد کرتے ہیں بنانا)، SaaS ٹولز جن کے پاس source code تک admin رسائی ہے، اور کیا employee offboarding کے لیے ایک single source of truth ہے۔ اس کے لیے ایک spreadsheet ٹھیک ہے۔ ابھی GRC platform کی ترجیح نہیں۔

پہلے 30 دن: کنٹرول سے زیادہ visibility

ہفتہ پہلے acceptable use policy لکھنے کی خواہش کا مقابلہ کریں۔ کوئی اسے نہیں پڑھے گا اور یہ اصل خطرات کو روک نہیں سکے گا۔ اس کی بجائے، تین چیزوں میں visibility حاصل کریں:

• Identity: اپنے identity provider (Okta, Google Workspace, Azure AD) سے مکمل یوزر لسٹ لیں اور HR کی فعال employee لسٹ کے خلاف cross-reference کریں۔ آپ کو ghost accounts ملیں گے۔
• Cloud footprint: اگر آپ AWS پر ہیں تو aws organizations list-accounts جیسی چیز چلائیں، یا GCP کے Asset Inventory کو دیکھیں، یہ دیکھنے کے لیے کہ کتنے environments موجود ہیں بمقابلہ کتنے کوئی memory سے نام دے سکتا ہے۔
• Code اور secrets exposure: gitleaks detect یا trufflehq filesystem . اپنے main repos کے خلاف چلائیں۔ دو سال پہلے کی commit history میں hardcoded API key تلاش کرنا تقریباً guaranteed ہے اور یہ value demonstrate کرنے کا تیز طریقہ ہے۔

نتائج کو دستاویز کریں، لیکن اسے 40-صفحہ کی رپورٹ میں نہ بدلیں جو کوئی نہیں کھولتا۔ پانچ bullet points والا ایک صفحہ کا risk summary CTO کے ذریعے پڑھا جاتا ہے۔ لمبا PDF نہیں۔

اپنے پہلے تین کنٹرول منتخب کرنا

کوئی headcount اور کوئی tooling budget نہیں ہے، آپ ایک ساتھ ہر چیز نہیں کر سکتے۔ Operations کی order جو کام کرتی ہے:

1. ہر جگہ MFA جہاں پہلے سے موجود نہیں ہے، identity provider سے شروع کریں، پھر GitHub/GitLab، پھر cloud consoles۔ یہ اکیلے سب سے عام account-takeover path کو بند کرتا ہے۔
2. Cloud اور auth events کے لیے Centralized logging۔ یہاں تک کہ SIEM-adjacent ٹول کا free tier، یا صرف CloudTrail/GCP audit logs کو bucket میں shipping کریں retention کے ساتھ، جب incident ہو تو کچھ نہ ہونے سے بہتر ہے۔
3. ایک لکھی ہوئی، مختصر incident response plan، حتیٰ کہ اگر یہ دو صفحات ہے: کون paged ہوتا ہے، کون customers سے بات کرتا ہے، کس کے پاس کسی چیز کو بند کرنے کا اختیار ہے۔ کوئی یہ بنانا یاد نہیں رکھتا جب تک کہ انہیں اس کی ضرورت نہ ہو، اور اس وقت تک بہت دیر ہو چکی۔

دیکھیں کہ ان میں سے کوئی بھی بڑے vendor contract کی ضرورت نہیں۔ انہیں decisions اور follow-through کی ضرورت ہے۔

سیکیورٹی budget line کے بغیر buy-in حاصل کرنا

پہلے سیکیورٹی hire کے طور پر credibility کھونے کا تیز ترین طریقہ کوئی نتائج دکھانے سے پہلے tools کی wishlist لے کر آنا ہے۔ اس کی بجائے، ہر مانگ کو کچھ concrete سے منسلک کریں: "ہم نے تین IAM users کو 2021 سے unrotated access keys کے ساتھ پایا" "ہمیں CSPM tool کی ضرورت ہے" سے بہتر ہے۔ درخواستیں ایسی شرائط میں frame کریں جن کی engineering اور finance پہلے سے پرواہ کرتے ہیں: کم blast radius، تیز audits، کم 2 a.m. pages۔ اگر کمپنی SOC 2 یا ISO 27001 کا شکار ہے، تو وہ compliance deadline اکثر وسائل حاصل کرنے کے لیے آپ کی بہترین leverage point ہے، یہاں تک کہ اگر compliance خود مقصد نہیں ہے۔

پہلے سال میں عام غلطیاں

آپ کے پاس عمل یا headcount ہے یا نہیں یہ معلوم کرنے سے پہلے مہنگے platform (SIEM, EDR, CSPM) خریدنا اصل میں جلدی budget کی سب سے عام بربادی ہے۔ ایک $50k ٹول جو کوئی tune نہیں کرتا noise پیدا کرتا ہے، detection نہیں۔ اسی طرح، template سے copied policies لکھنا بغیر اس کے adapt کیے کہ کمپنی اصل میں کیسے کام کرتی ہے اس بات کی guarantee دیتا ہے کہ وہ پہلی بار ignore ہوں گے جب کسی کو exception کی ضرورت ہو۔ اور سب کچھ سوالو پہلے چھ ماہ کے بعد own کرنے کی کوشش ایک burnout path ہے؛ جس لمحے traction ہو، اگلی hire عام طور پر وہ شخص ہونا چاہیے جو detection اور response کو own کر سکتا ہے تاکہ آپ program structure بنانا جاری رکھ سکیں۔

صفر سے Security زیادہ تر sequencing کے بارے میں ہے: دیکھو کہ کیا موجود ہے، سب سے بلند gaps بند کریں، اتنا process بنائیں کہ decisions آپ کی memory پر منحصر نہ ہوں، اور وہاں سے expand کریں۔

اگر اس قسم کی ground-level program building آپ کو دلچسپی دیتی ہے، Korra Studio کے پاس incident response fundamentals اور cloud security posture پر متعلقہ segments ہیں جو اس کے ساتھ اچھی طرح match کرتے ہیں۔