नीतियाँ लिखने से पहले कंप्लायंस टूल्स खरीदना बंद करें

एक परिचित क्रम: कंपनी को SOC 2 या ISO 27001 की ज़रूरत पड़ती है, कोई शोध करता है, और पहली खरीद एक tool होता है: एक compliance platform, एक endpoint suite, एक SIEM, या एक policy generator। कुछ महीने बाद tool आधा कॉन्फ़िगर होता है, उसके alerts नज़रअंदाज़ हो जाते हैं और auditor ऐसे सवाल पूछ रहा होता है जिनका जवाब वह tool नहीं दे पाता। समस्या tool नहीं थी। समस्या क्रम की थी।

Tools निर्णयों को लागू करते हैं

किसी भी control के लिए किसी tool के काम आने से पहले कुछ निर्णय ज़रूरी हैं: दायरे में क्या है, उसका मालिक कौन है, वह कितनी बार चलता है, "अच्छा" का क्या मतलब है और विफल होने पर क्या होता है। ये निर्णय ही आपकी नीति और प्रक्रिया हैं। इनके बिना vulnerability scanner खरीदें तो आपको हज़ारों findings मिलेंगी जिनकी जवाबदेही किसी की नहीं होगी; इनके बिना SIEM खरीदें तो आपको ऐसे logs मिलेंगे जिन्हें कोई नहीं पढ़ेगा।

फ़्रेमवर्क एक मत हैं

कोई भी प्रमुख फ़्रेमवर्क किसी खास product की माँग नहीं करता। ISO 27001 नीतियाँ, जोखिम उपचार और ऐसे controls माँगता है जो प्रभावी रूप से चलें। SOC 2 पूछता है कि controls डिज़ाइन किए गए हैं और प्रभावी ढंग से काम करते हैं या नहीं। PCI DSS अपनी बारह में से हर आवश्यकता की शुरुआत दस्तावेज़ीकृत नीतियों, प्रक्रियाओं और सौंपी गई भूमिकाओं से करता है। ये सब मानकर चलते हैं कि सोच-विचार पहले आता है।

बेहतर क्रम

1. दायरा और जोखिम: हम क्या सुरक्षित कर रहे हैं, किससे, और कौन से फ़्रेमवर्क लागू होते हैं? एक गैप विश्लेषण दिखाता है कि अगला फ़्रेमवर्क आपके मौजूदा ढांचे में क्या जोड़ता है।
2. हर control तय करें: मालिक, आवृत्ति, मानक और evidence। इसे संक्षेप में लिखें; यही आपका नीति-समूह है (देखें कई फ़्रेमवर्क के लिए एक नीति-समूह)।
3. जहाँ संभव हो, पहले इसे हाथ से चलाएँ। स्प्रेडशीट में एक त्रैमासिक access review आपको बताता है कि tool से क्या चाहिए।
4. फिर उन निर्णयों को स्वचालित करने वाले tools खरीदें जो आप पहले ही ले चुके हैं, और उन्हें उन्हीं निर्णयों के आधार पर परखें।

जब tools पहले आएँ, और काम बाद में

अपवाद भी हैं। Endpoint protection, MFA और backups तुरंत लागू करने लायक हैं, क्योंकि उनका मूल्य fine-tuning पर निर्भर नहीं करता। और compliance platforms, जो नीतियाँ लिखने और controls को ट्रैक करने में मदद करते हैं, दूसरे चरण को तेज़ कर सकते हैं, बशर्ते आप उनके templates और mappings को draft मानें, अंतिम उत्तर नहीं (हमने ऐसे क्रॉसवॉक के बारे में लिखा है जिनकी जाँच नहीं हो सकती)।

पहले निर्णय लेने का स्वरूप

Vulnerability management को लीजिए, वह control जो सबसे अधिक एक product के रूप में खरीदा जाता है। कोई scanner चुनने से पहले तय करें:

• दायरा: कौन सी assets scan होंगी (internal, external, cloud, containers) और आप कैसे जानेंगे कि asset list पूरी है।
• आवृत्ति: PCI DSS हर तीन महीने पर और महत्वपूर्ण बदलावों के बाद internal scans माँगता है; CIS Controls internal और external assets के स्वचालित scans माँगते हैं; आपका अपना जोखिम इससे अधिक माँग सकता है।
• गंभीरता और समय-सीमाएँ: findings को कैसे rate किया जाता है और हर गंभीरता स्तर को कितनी जल्दी ठीक करना होगा।
• स्वामित्व: findings को कौन triage करता है, कौन ठीक करता है, और जब कोई चीज़ ठीक नहीं हो सकती तो जोखिम कौन स्वीकार करता है।
• Evidence: कौन सी रिपोर्ट यह साबित करती है कि control चला और findings संभाली गईं।

इन पाँचों उत्तरों को लिखकर रखने के बाद tool का मूल्यांकन सरल हो जाता है: क्या यह दायरा कवर करता है, तय आवृत्ति पर चलता है, गंभीरता को आपके तरीके से rate करता है और evidence देता है? इनके बिना हर demo प्रभावशाली लगता है, पर उनमें से कोई भी आपके audit का जवाब नहीं देता। यही अभ्यास logging, endpoint protection और access management पर भी लागू होता है। हमारे विषय पेज दिखाते हैं कि हर फ़्रेमवर्क हर control के लिए क्या माँगता है, जो निर्णयों के लिए एक अच्छी checklist है, और vulnerability management विषय से शुरुआत करना अच्छा रहेगा।

मुख्य बिंदु

• Tools निर्णयों को लागू करते हैं; दायरा, मालिक, आवृत्ति और evidence तय करने के बाद ही उन्हें खरीदें।
• कोई भी प्रमुख फ़्रेमवर्क किसी खास product की माँग नहीं करता।
• अगर संभव हो तो पहले control को हाथ से चलाएँ, फिर उसे स्वचालित करें।

परीक्षण

खरीदने से पहले पूछें: यह किस control को लागू करता है, उस control का मालिक कौन है, और यह कौन सा evidence बनाएगा? अगर कोई उत्तर नहीं दे पाता, तो खरीदारी जल्दबाज़ी है।

प्रश्न

पहले क्या आना चाहिए, नीतियाँ या tools?

पहले निर्णय: दायरा, जोखिम, और संगठन हर control को कैसे चलाएगा (कौन, कितनी बार, किस मानक पर)। लिखे जाने पर ये निर्णय ही आपकी नीतियाँ और प्रक्रियाएँ हैं; tools फिर उन्हें लागू करते हैं।

क्या auditors को किसी खास tool की ज़रूरत होती है?

कोई भी प्रमुख फ़्रेमवर्क किसी खास product की माँग नहीं करता। Auditors ऐसे controls देखते हैं जो प्रभावी ढंग से चलें और evidence बनाएँ, चाहे उन्हें किसी भी तरीके से लागू किया गया हो।

क्या compliance automation platform लेना फ़ायदेमंद है?

हो सकता है, जब आप जान लें कि आप कौन से controls चलाते हैं और उनका मालिक कौन है। Platforms अनुस्मारक, evidence जुटाने और ट्रैकिंग में अच्छे हैं; वे आपके लिए दायरा या जोखिम की स्वीकार्यता तय नहीं कर सकते।