रनबुक में जिसे कोई नहीं डालता, वह restore चरण

हमने जो भी recovery plan पढ़ा है, उसका मूल्यांकन इस बात पर किया जाता है कि data कितनी जल्दी वापस आता है. Recovery time objective, recovery point objective, downtime के घंटे, प्रति घंटे खोया गया revenue. ये board slide पर लिखे numbers हैं, और recovery को जो कुछ करना होता है, उसके लिए ये सही numbers हैं।

यही कारण भी हैं कि region के लगभग हर runbook में एक step गायब है।

दो तारीखें

Timeline से शुरू करें, क्योंकि timeline ही पूरा mechanism है।

आप एक दिन compromise होते हैं। आपको किसी बाद के दिन पता चलता है, क्योंकि dwell time यही है: intruder के आने और किसी के उसे नोटिस करने के बीच का interval। इसे minutes की बजाय days या weeks में मापें। सटीक figure incident के अनुसार बदलता है और उसके आकार की तुलना में कम महत्वपूर्ण होता है।

अब पूछिए कि recovery team किस backup को चुनती है। वे सबसे recent restore point चुनते हैं जिसे clean माना जाता है। व्यवहार में इसका मतलब है incident के detected होने से पहले लिया गया सबसे recent restore point, क्योंकि detection ही वह एकमात्र event है जिसकी timestamp पर सभी सहमत होते हैं।

वे दो अलग-अलग dates हैं। उनके बीच के gap में बनाया, प्राप्त किया या बदला गया सब कुछ backup के अंदर है, और जिस malicious document ने incident शुरू किया था, वह लगभग निश्चित रूप से किसी के कुछ नोटिस करने से पहले ही बनाया गया था। Backup एक faithful copy है। Payload के मामले में भी वह faithful है।

वह metric जो step को हटा देती है

यह वह हिस्सा है जिस पर कम ध्यान जाता है, और यह बिल्कुल भी technology problem नहीं है।

Recovery का मूल्यांकन elapsed time पर किया जाता है। Estate के down रहने का हर hour गिना जाता है, अक्सर ऐसे लोग इसे गिनते हैं जो revenue figure देख रहे होते हैं। हर restored document की inspection या reprocessing recovery lead पर लगाए जा रहे judgment के ठीक उसी number में hours जोड़ देती है, और यह उन्हें सबसे खराब संभव moment पर जोड़ती है, जब incident को खत्म घोषित करने का दबाव सबसे अधिक होता है।

कोई भी runbook में "we skipped file hygiene" नहीं लिखता। ऐसा नहीं होता। Step कभी runbook में था ही नहीं, किसी metric ने कभी इसकी माँग नहीं की, और recovery समय पर पूरी हो गई। Incentive ने चुपचाप काम कर दिया।

तो pattern दोहराता है: servers clean images से rebuild किए जाते हैं, credentials rotate किए जाते हैं, endpoints reimage किए जाते हैं, network इस बार ठीक से segment किया जाता है। फिर fileshares, mailboxes और document repositories बिल्कुल वैसे ही वापस आ जाते हैं जैसे वे थे। Unchanged. एकमात्र layer जिसे कोई reconstruct नहीं करता, वह layer है जिसने उस चीज़ को अंदर पहुँचाया था।

Re-scanning गलत instrument क्यों है

स्पष्ट उत्तर है restore करने से पहले backup को scan करना, और यह ठीक-ठीक समझना उपयोगी है कि यह सुनने में जितना लगता है, उससे कमज़ोर क्यों है।

आपका detection stack इस file को पहले ही पहचानने में विफल रहा था, जिस दिन यह आया था। restore time पर आप engine की उसी class को उसी file पर point कर रहे हैं, और known-bad चीज़ों की उसी catalogue को ढूँढ़ रहे हैं। अगर campaign noisy था और व्यापक रूप से report हुआ था, तो signatures शायद catch up कर चुके हों। अगर ऐसा नहीं था, या document खास तौर पर आपके लिए बनाया गया था, तो उन्होंने catch up नहीं किया होगा।

एक sandbox की भी एक संबंधित limit होती है: वह उतना ही अच्छा होता है जितना उसे design किया गया है। ऐसा payload जो user interaction, किसी specific locale, या ऐसी date का इंतज़ार करता है जो अभी आई नहीं है, detonation के दौरान impeccably behave करता है, और ठीक उतनी ही देर तक impeccably behave करता है जितनी उसे चाहिए।

एक और शांत failure भी होता है। Re-scanning एक verdict पैदा करता है, और verdict evidence नहीं होता। "Nothing found" आपके detection coverage के बारे में एक statement है, file के बारे में नहीं।

restore-hygiene step कैसा दिखता है

काम करने वाला version backup से निकलने वाली file को उसी तरह treat करता है जैसे आप किसी stranger से आने वाली file को करते, क्योंकि recovery के दौरान उसकी provenance बिल्कुल वही होती है।

ठोस रूप से, restore और service में वापस लौटाने के बीच एक step जोड़ा जाता है:

1. निरीक्षण करने के बजाय पुनर्निर्माण करें। प्रत्येक दस्तावेज़ को उसके अवयवों में विभाजित करें, उस प्रारूप के लिए प्रकाशित विनिर्देश के विरुद्ध हर एक को सत्यापित करें, फिर उस मध्यवर्ती प्रतिनिधित्व से एक बिल्कुल नई फ़ाइल बनाएं: नुस्खा, मूल बाइट्स नहीं। यह अंतर जितना लगता है उससे अधिक महत्वपूर्ण है। इंजन जिन भागों को अच्छा मानता है, उन्हें कॉपी करना अभी भी इस बारे में एक निर्णय है कि क्या सुरक्षित दिखता है, जो अलग रूप में detection है, और मूल फ़ाइल अभी भी वही है जो आती है। एक rebuild मूल को बिल्कुल भी पास नहीं होने देता, इसलिए कुछ भी बिना पहचाने बच नहीं निकलता। यही deterministic Content Disarm and Reconstruction करता है; Glasswall 8.27 million tested में 100% malicious files neutralised होने की रिपोर्ट करता है, और इसका government research centre case study इस तरह sequenced recovery का वर्णन करता है।
2. प्रति फ़ाइल रिकॉर्ड रखें। प्रत्येक दस्तावेज़ के लिए, क्या हटाया गया, किस policy के तहत, किस समय। यह वह artefact है जिसकी आपके incident report को आवश्यकता है और वह artefact है जिसे एक assessor मांगता है, और इसे बाद में पुनर्निर्मित नहीं किया जा सकता।
3. वर्णक्रमानुसार नहीं, blast radius के आधार पर प्राथमिकता दें। Shared drives, mailboxes और कोई भी चीज़ जिसे automated pipeline consume करता है, पहले आते हैं। एक finance share जो monthly macro-driven process को feed करती है, एक archive से अधिक उच्च-स्तरीय समस्या है जिसे कोई नहीं खोलता।
4. मान लें कि estate अभी भी islanded है। Mid-recovery में अक्सर फ़ाइलें भेजने के लिए कोई network नहीं होता, इसलिए desktop-resident processing यहाँ उस तरह महत्वपूर्ण है जैसा steady state में नहीं होता। Glasswall Meteor engine को locally चलाता है, online, offline या air-gapped.

इनमें से कुछ भी glamorous नहीं है, और इनमें से कुछ भी नया engineering नहीं है। यह एक step है और घंटे खर्च करने का एक निर्णय है।

evidence वाला आधा

इस step को जोड़ने का दूसरा कारण यह है कि इस region में obligation पहले से ही लिखी हुई है, और यह उतनी ही evidence obligation है जितनी control obligation।

Singapore's Cybersecurity Code of Practice for Critical Information Infrastructure clause 6.1.4 में इसे साफ़ कहता है: logs को उस event के बाद कम से कम twelve months तक रखा जाए जिसे वे record करते हैं, unauthorised modification और deletion से protected रखा जाए, और "governed by a log retention policy to facilitate investigations into cybersecurity incidents"। Retention जिसका stated purpose investigation है, archive नहीं।

MAS Technology Risk Management Guidelines financial institutions के लिए parallel expectation तय करते हैं: mail, upload portal या third-party exchange से आने वाली untrusted files को boundary पर ही handle किया जाता है, केवल detection verdict के आधार पर उन्हें admit नहीं किया जाता।

Incident के बाद इन दोनों को साथ पढ़ें, और assessor के साथ आने वाला सवाल "आपने क्या block किया" नहीं होता। वह होता है "मुझे दिखाइए इस document के साथ क्या हुआ"। जो control केवल exceptions record करता है, वह इसका जवाब नहीं दे सकता, क्योंकि जिन files को उसने अंदर जाने दिया, उनके लिए कोई per-file record बना ही नहीं। एक rebuild step हर उस file के लिए एक record बनाता है जिसे वह touch करता है, उन files सहित जो पूरी तरह ठीक निकलीं, और यही record को evidence के रूप में usable बनाता है, alert history के रूप में नहीं।

पूछने लायक सवाल

Recovery plans का rehearsal किया जाता है। Restore-hygiene steps दूसरे incident के बाद जोड़े जाते हैं, जो इसे सीखने की एक महँगी जगह है।

अगर recovery sign-off पर आपका signature जाता है, तो आपकी team के लिए सवाल यह नहीं है कि data कितनी तेज़ी से वापस आया। सवाल यह है कि हमने क्या वापस रखा, और हमें यह कैसे पता।

Singapore में पूरी obligation picture के लिए, जिसमें Cybersecurity (Amendment) Act 2024 और July 2026 में घोषित CCoP update शामिल हैं, हमारा Singapore compliance page देखें।