آپ ایک incident response plan کیسے بناتے ہیں جو کام کرے؟

بیشتر organizations incident response میں ناکام نہیں ہوتے کیونکہ انہیں tools کی کمی ہے۔ وہ ناکام ہوتے ہیں کیونکہ پہلے سے کوئی متفق نہیں تھا کہ کون کیا کرے گا، اور پہلی حقیقی incident ایک response کی بجائے ایک میٹنگ بن جاتی ہے۔

Phases سے شروع کریں، playbook سے نہیں

NIST SP 800-61 چار phases کی تشریح کرتا ہے: preparation، detection and analysis، containment/eradication/recovery، اور post-incident activity۔ یہ ترتیب اہم ہے۔ Teams براہ راست containment کی طرف جانے سے محبت کرتے ہیں کیونکہ یہ محنت مندانہ لگتا ہے، لیکن اگر آپ نے preparation کا کام نہیں کیا تو آپ اپنے network کو اتنی اچھی طرح نہیں جانتے کہ کسی چیز کو صاف ستھرے سے containment کر سکیں۔

Preparation کا مطلب ہے asset inventories جو واقعی موجودہ ہیں، 2022 کی spreadsheet نہیں۔ اس کا مطلب ہے اپنی log retention window کو جاننا (اگر یہ 7 دن ہے اور attacker کے پاس 30 دن کا dwell time تھا تو آپ نے پہلے سے timeline کھو دی ہے)۔ اس کا مطلب ہے پہلے سے تیار forensic tooling — Velociraptor، KAPE، یا یہاں تک کہ disk images کے لیے ایک documented tar/dd procedure — تاکہ کوئی بھی active incident کے دوران ایک compromised host پر tools download نہ کرے۔

Severity levels کو define کریں اس سے پہلے کہ آپ کو ان کی ضرورت ہو

ایک SEV1 (active data exfiltration، ransomware detonation، domain admin compromise) کو ایک SEV3 (ایک unprivileged workstation پر isolated malware) سے مختلف response کی ضرورت ہے۔ اسے ایک matrix میں لکھیں: impact بمقابلہ scope بمقابلہ confidence۔ ہر severity کو ایک ضروری response time اور ایک escalation path assign کریں۔ اگر ایک SEV1 کے لیے آپ کا incident commander وہی شخص ہے جو ہر $500 کے purchase order کو منظور کرنے کے لیے ہے تو آپ نے اپنے emergency process میں ایک bottleneck بنایا ہے۔

Incident commander کا role لازمی ہے

ایک شخص incident کو چلاتا ہے۔ default سے سب سے سینئر engineer نہیں — وہ شخص جو coordinate کرنے، delegate کرنے، اور دباؤ میں containment کے فیصلے کرنے کے لیے بہترین ہے۔ یہ شخص response کے دوران ضروری نہیں کہ keyboard کو چھوئے؛ وہ timeline کو track کرتے ہیں، legal اور leadership کے ساتھ communication کو manage کرتے ہیں، اور یہ فیصلہ کرتے ہیں کہ کب ایک segment کو isolate کرنے یا ایک system کو offline لے جانے کا trigger pull کریں۔

اس role کے بغیر، آپ کو پانچ لوگ ایک جیسے box میں SSH'd ملتے ہیں، ان میں سے کوئی ایک دوسرے سے بات نہیں کر رہا، اور کوئی بھی volatile memory کو capture نہیں کر رہا جس سے پہلے کوئی "دیکھنے کے لیے کہ کیا یہ ٹھیک ہو جاتا ہے" machine کو reboot کر دے۔

Containment کے فیصلے جو واقعی اہم ہیں

زیادہ تر incidents میں سب سے مشکل فیصلہ یہ ہے: ابھی isolate کریں یا scope کو سمجھنے کے لیے ایک اور دیر observe کریں؟ بہت جلدی network access کو pull کرنا ایک ایسے attacker کو تنبیہ دیتا ہے جو ابھی بھی laterally move کر رہا ہے اور آپ کے ان کے اگلے move کو دیکھنے کے موقع کو تباہ کرتا ہے۔ بہت لمبا انتظار کرنا ransomware کو shares کو encrypt کرنا مکمل کرنے دیتا ہے۔

ایک معقول درمیانی راہ: network segmentation اور EDR isolation (CrowdStrike، Defender for Endpoint، SentinelOne سب اس کی support کرتے ہیں) استعمال کریں ایک host کو lateral movement سے کاٹ دینے کے لیے جبکہ اسے memory capture کے لیے چالو رکھیں۔ مکمل shutdown آخری حربہ ہونا چاہیے — یہ volatile evidence کو ختم کرتا ہے اور ransomware کے cases کے لیے anti-forensic behavior کو trigger کر سکتا ہے جو کچھ payloads میں بنی ہوئی ہے۔

Logging gaps جن سے آپ کو پہلے نہیں پہلے پچھتاوا ہوگا

Windows Event Log defaults کافی نہیں ہیں۔ اگر آپ کے پاس Sysmon deployed نہیں ہے ایک معقول config کے ساتھ (SwiftOnSecurity یا Olaf Hartong کے baseline configs ایک ٹھوس starting point ہیں) تو آپ process trees کو fragments سے reconstruct کر رہے ہوں گے۔ Network کی طرف سے NetFlow یا Zeek logs سب سے زیادہ organizations سے کہیں زیادہ معاملات کر سکتے ہیں جب تک انہیں جواب دینے کی ضرورت نہ ہو