शून्य से सुरक्षा कार्यक्रम बनाना

किसी कंपनी में पहले सुरक्षा व्यक्ति के रूप में नियुक्त होना एक विशिष्ट तरह की अराजकता है। कोई टिकट कतार नहीं है, कोई स्थापित उपकरण नहीं हैं, और आमतौर पर आपके लिए इंतजार करने के लिए कोई बजट लाइन नहीं है। आगे वह एक मोटा नक्शा है कि वह पहला 90-180 दिन आमतौर पर कैसे जाता है, और वास्तव में क्या लाभ पहुंचाता है बनाम क्या सिर्फ उत्पादक महसूस होता है।

"कुछ नहीं" आमतौर पर क्या मतलब है

जब लोग कहते हैं कि एक कंपनी के पास कोई सुरक्षा कार्य नहीं है, तो वे शायद ही कभी शून्य नियंत्रण का मतलब रखते हैं। उनका मतलब है कोई समर्पित मालिक नहीं। इंजीनियरिंग ने संभवतः कुछ बुनियादी AWS IAM नीतियों को सक्षम किया है, IT के पास एक MDM टूल के माध्यम से कुछ एंटीवायरस है, और वित्त में किसी के पास SOC 2 के बारे में विचार हैं क्योंकि एक ग्राहक ने पूछा। आपकी पहली नौकरी कार्यान्वयन नहीं, इन्वेंटरी है। एक भी नीति लिखने से पहले, यह पता लगाएं कि क्या पहले से चल रहा है: क्लाउड खाते (और कितने किसी को याद नहीं हैं बनाने के), SaaS टूल जिनके पास स्रोत कोड तक व्यवस्थापक पहुंच है, और क्या कर्मचारी offboarding के लिए सत्य का एक एकल स्रोत है। एक स्प्रेडशीट इसके लिए ठीक है। एक GRC प्लेटफॉर्म अभी तक प्राथमिकता नहीं है।

पहले 30 दिन: दृश्यमानता नियंत्रण पर

सप्ताह एक में एक स्वीकार्य उपयोग नीति लिखने की इच्छा का विरोध करें। कोई इसे नहीं पढ़ेगा और यह वास्तविक जोखिमों को नहीं रोकेगा। इसके बजाय, तीन चीजों में दृश्यमानता प्राप्त करें:

• Identity: अपने identity provider (Okta, Google Workspace, Azure AD) से एक पूर्ण उपयोगकर्ता सूची खींचें और HR की सक्रिय कर्मचारी सूची के विरुद्ध क्रॉस-संदर्भ करें। आप ghost accounts खोजेंगे।
• Cloud footprint: कुछ चलाएं जैसे aws organizations list-accounts यदि आप AWS पर हैं, या GCP की Asset Inventory देखें, यह देखने के लिए कि कितने वातावरण मौजूद हैं बनाम कितने किसी को स्मृति से नाम दे सकते हैं।
• Code and secrets exposure: अपने मुख्य repos के विरुद्ध gitleaks detect या trufflehog filesystem . चलाएं। दो साल पहले प्रतिबद्ध इतिहास में एक hardcoded API key खोजना लगभग गारंटीकृत है और यह मूल्य प्रदर्शित करने का एक तेज़ तरीका है।

निष्कर्ष दस्तावेज़ करें, लेकिन इसे एक 40-पृष्ठ रिपोर्ट में न बदलें जो कोई नहीं खोलता। एक पृष्ठ जोखिम सारांश जिसमें पांच बुलेट पॉइंट हों, एक CTO द्वारा पढ़ा जाता है। एक लंबी PDF नहीं।

अपने पहले तीन नियंत्रणों को चुनना

कोई headcount और कोई उपकरण बजट के साथ, आप एक बार में सब कुछ नहीं कर सकते। संचालन का क्रम जो काम करता है:

1. MFA हर जगह जहां यह पहले से नहीं है, identity provider से शुरू करते हुए, फिर GitHub/GitLab, फिर cloud consoles। यह अकेले सबसे आम खाता-अधिग्रहण पथ को बंद कर देता है।
2. Cloud और auth events के लिए केंद्रीकृत logging। यहां तक ​​कि एक SIEM-adjacent tool का एक मुक्त स्तर, या बस CloudTrail/GCP audit logs को किसी bucket में प्रतिधारण के साथ भेजना, जब कोई घटना होती है तो कुछ न होने से बेहतर है।
3. एक लिखित, संक्षिप्त incident response plan, भले ही यह दो पृष्ठ हो: कौन paged हो, कौन ग्राहकों से बात करे, किसके पास कुछ बंद करने का अधिकार है। कोई भी इसे तब तक बनाने के लिए याद नहीं करता जब तक उन्हें इसकी आवश्यकता न हो, और तब तक देर हो चुकी होती है।

ध्यान दें कि इनमें से कोई भी एक बड़े विक्रेता अनुबंध की आवश्यकता नहीं है। उन्हें निर्णय और follow-through की आवश्यकता है।

सुरक्षा बजट लाइन के बिना buy-in प्राप्त करना

पहली सुरक्षा नियुक्ति के रूप में विश्वसनीयता खोने का सबसे तेज़ तरीका कोई परिणाम दिखाने से पहले उपकरणों की एक इच्छा सूची के साथ दिखना है। इसके बजाय, हर माँग को कुछ concrete से जोड़ें: "हमने 2021 से unrotated access keys वाले तीन IAM उपयोगकर्ता पाए" "हमें एक CSPM tool की जरूरत है" से बेहतर लगता है। अनुरोधों को उन शर्तों में frame करें जो इंजीनियरिंग और वित्त पहले से care करते हैं: reduced blast radius, तेज़ audits, कम 2 a.m. pages। यदि कंपनी SOC 2 या ISO 27001 का पीछा कर रही है, तो वह compliance deadline अक्सर संसाधन प्राप्त करने के लिए आपका सर्वश्रेष्ठ leverage point है, यहां तक ​​कि अगर compliance स्वयं लक्ष्य नहीं है।

पहले साल में सामान्य गलतियां

आपके पास वास्तव में इसे संचालित करने के लिए प्रक्रिया या headcount होने से पहले एक महंगा platform (SIEM, EDR, CSPM) खरीदना प्रारंभिक बजट की सबसे आम बर्बादी है। एक $50k tool जिसे कोई tune नहीं करता, detection नहीं, शोर उत्पन्न करता है। इसी तरह, एक template से नीतियां लिखना उन्हें अनुकूलित किए बिना कि कंपनी वास्तव में कैसे काम करती है, गारंटी देता है कि उन्हें पहली बार ignore किया जाएगा जब किसी को एक exception की आवश्यकता हो। और छह महीने के बाद सब कुछ अकेले own करने की कोशिश एक burnout path है; जिस क्षण traction हो, अगली नियुक्ति आमतौर पर कोई होनी चाहिए जो detection और response को own कर सके ताकि आप program structure बनाते रह सकें।

शून्य से सुरक्षा अधिकतर sequencing के बारे में है: देखें कि क्या मौजूद है, सबसे जोर से gaps को बंद करें, इतनी प्रक्रिया बनाएं कि निर्णय आपकी स्मृति पर निर्भर न हों, और वहां से विस्तार करें।

यदि इस तरह का ground-level program building आपको रुचि देता है, तो Korra Studio के पास incident response fundamentals और cloud security posture पर संबंधित segments हैं जो इस एक के साथ अच्छी तरह मेल खाते हैं।