आप एक इनसिडेंट रेस्पांस प्लान कैसे बनाते हैं जो काम करे?

अधिकांश संगठन इनसिडेंट रेस्पांस में विफल नहीं होते क्योंकि उनके पास टूल नहीं हैं। वे विफल होते हैं क्योंकि पहले से किसी ने सहमति नहीं दी कि कौन क्या करता है, और पहली वास्तविक इनसिडेंट एक रेस्पांस की बजाय एक मीटिंग बन जाती है।

प्लेबुक से नहीं, चरणों से शुरू करें

NIST SP 800-61 चार चरणों को निर्दिष्ट करता है: preparation, detection and analysis, containment/eradication/recovery, और post-incident activity। यह क्रम महत्वपूर्ण है। टीमें सीधे containment पर जाना पसंद करती हैं क्योंकि यह उत्पादक लगता है, लेकिन अगर आपने preparation का काम नहीं किया है, तो आप अपने नेटवर्क को काफी अच्छी तरह नहीं जानते कि कुछ भी साफ तरीके से contain कर सकें।

Preparation का मतलब asset inventories हैं जो वास्तव में वर्तमान हों, 2022 की स्प्रेडशीट नहीं। इसका मतलब है कि आप अपनी log retention window जानते हैं (अगर यह 7 दिन है और हमलावर के पास 30 दिन का dwell time है, तो आपने पहले ही timeline खो दी है)। इसका मतलब pre-staged forensic tooling है — Velociraptor, KAPE, या यहां तक कि एक दस्तावेजित tar/dd procedure disk images के लिए — ताकि कोई भी एक सक्रिय इनसिडेंट के दौरान एक compromised host पर टूल डाउनलोड न करे।

गंभीरता के स्तर को परिभाषित करें इससे पहले कि आपको उनकी आवश्यकता हो

एक SEV1 (सक्रिय data exfiltration, ransomware detonation, domain admin compromise) को SEV3 (एक unprivileged workstation पर isolated malware) से अलग रेस्पांस की आवश्यकता होती है। इसे एक मैट्रिक्स के रूप में लिखें: impact vs. scope vs. confidence। प्रत्येक गंभीरता स्तर को एक आवश्यक response time और एक escalation path असाइन करें। अगर आपकी SEV1 की incident commander वह व्यक्ति है जिसे हर $500 purchase order को approve करना है, तो आपने अपनी खुद की emergency process में एक bottleneck बना दिया है।

इनसिडेंट कमांडर की भूमिका optional नहीं है

एक व्यक्ति इनसिडेंट चलाता है। डिफ़ॉल्ट रूप से सबसे सीनियर इंजीनियर नहीं — वह व्यक्ति जो दबाव में coordinate, delegate, और containment calls करने के लिए सबसे उपयुक्त हो। यह व्यक्ति रेस्पांस के दौरान जरूरी नहीं कि keyboard को छुए; वे timeline को ट्रैक करते हैं, legal और leadership के साथ communication को manage करते हैं, और यह तय करते हैं कि एक segment को isolate करने या एक system को offline लेने के लिए कब trigger खींचा जाए।

इस भूमिका के बिना, आप पाँच लोगों को एक ही box में SSH'd देखते हैं, उनमें से कोई भी एक दूसरे से बात नहीं कर रहा है, और कोई भी volatile memory को capture नहीं कर रहा है इससे पहले कि कोई यह "देखने के लिए कि यह इसे ठीक करता है" machine को reboot करे।

Containment के फैसले जो वास्तव में महत्वपूर्ण हैं

अधिकांश incidents में सबसे कठिन call यह है: अभी isolate करें, या scope को समझने के लिए थोड़ा और observe करें? network access को बहुत जल्दी pull करने से एक अभी भी laterally move कर रहे हमलावर को tip off होता है और आपकी उनकी अगली move को देखने की chance को destroy करता है। बहुत लंबे wait करने से ransomware shares को encrypt करना खत्म कर देता है।

एक reasonable middle ground: network segmentation और EDR isolation (CrowdStrike, Defender for Endpoint, SentinelOne सभी इसे support करते हैं) का use करके एक host को lateral movement से cut off करें जबकि memory capture के लिए इसे powered on रखें। Full shutdown एक last resort होना चाहिए — यह volatile evidence को kill करता है और, ransomware cases के लिए, कुछ payloads में baked anti-forensic behavior को trigger कर सकता है।

Logging gaps जिसे आप पहले नहीं, बल्कि during regret करेंगे

Windows Event Log defaults पर्याप्त नहीं हैं। अगर आपके पास Sysmon deployed नहीं है एक decent config के साथ (SwiftOnSecurity's या Olaf Hartong's baseline configs एक solid starting point हैं), तो आप process trees को fragments से reconstruct कर रहे होंगे। Network side पर, NetFlow या Zeek logs अधिकांश orgs को realize करने से ज्यादा महत्वपूर्ण हैं जब तक कि उन्हें answer की आवश्यकता नहीं होती