Agentic सिस्टम्स के लिए इंसिडेंट रिस्पॉन्स
पिछले पाठ में पहले दस मिनट के बारे में बताया गया था। यह पाठ इसे एक कंपनी प्लेबुक में बदलता है: भूमिकाएं (roles), कदम, सबूत, सफाई (clean-up) और इसका अभ्यास करने के लिए एक टेबलटॉप एक्सरसाइज़।
60 सेकंड में
Agentic सिस्टम्स के लिए इंसिडेंट रिस्पॉन्स
पिछले पाठ में पहले दस मिनट के बारे में बताया गया था। यह पाठ इसे एक कंपनी प्लेबुक में बदलता है: भूमिकाएं (roles), कदम, सबूत, सफाई (clean-up) और इसका अभ्यास करने के लिए एक टेबलटॉप…
प्लेबुक
- 1
पहचानना (Detect)
गेटवे और लॉग्स से अलर्ट्स (पहली बार इस्तेमाल हुआ टूल, अचानक स्पाइक, नया डेस्टिनेशन, DLP हिट), यूज़र रिपोर्ट्स, या किसी पार्टनर द्वारा सूचित किया जाना। - 2
रोकथाम (Contain)
एजेंट या टूल के लिए किल स्विच का इस्तेमाल करें। इसके टोकन्स और OAuth ग्रांट्स रीवोक (रद्द) करें। अगर कारण साफ़ न हो, तो सभी एजेंट्स के लिए जोखिम भरे टूल्स को डिसेबल कर दें। - 3
सबूत सुरक्षित रखना (Preserve evidence)
कुछ भी एक्सपायर होने से पहले टूल-कॉल लॉग्स, बातचीत का कॉन्टेक्स्ट, मेमोरी स्टोर्स, हासिल किए गए डॉक्यूमेंट्स और कॉन्फ़िगरेशन का स्नैपशॉट लें। - 4
जांच करना (Investigate)
हर एक्शन की लिस्ट बनाने के लिए correlation IDs का इस्तेमाल करें। पहली गलत हरकत से ठीक पहले पढ़ा गया कॉन्टेंट खोजें। पहले के रन और उसी सोर्स का इस्तेमाल करने वाले अन्य एजेंट्स की जांच करें। - 5
जड़ से मिटाना (Eradicate)
पॉइज़न की गई मेमोरी एंट्रीज़, डॉक्यूमेंट्स, टिकट्स या टूल के विवरणों को हटाएं। पॉलिसी या परमिशन्स की कमियों को ठीक करें। - 6
रिकवर करना (Recover)
साफ़ (क्लीन) स्टेट से रीस्टोर करें, एक्सपोज़ हुए सीक्रेट्स को रोटेट करें, सख्त सीमाओं के साथ फिर से इनेबल करें, और बारीकी से निगरानी रखें। - 7
सीखना (Learn)
ब्लेम-लेस रिव्यू (बिना किसी पर दोष मढ़े समीक्षा): क्या हुआ, सुरक्षा नियंत्रणों से यह कैसे छूट गया, और क्या बदलाव किए जाने हैं। टेस्ट्स और अलर्ट्स जोड़ें।
कौन क्या करता है
| भूमिका (Role) | ज़िम्मेदारी |
|---|---|
| इंसिडेंट लीड | रिस्पॉन्स संभालते हैं, रोकथाम से जुड़े फैसले लेते हैं, और टाइमलाइन बनाए रखते हैं |
| एजेंट ओनर | जानते हैं कि एजेंट किसलिए है, यह कहां तक पहुंच सकता है, और इसके सामान्य (नॉर्मल) कामकाज का तरीका क्या है |
| प्लेटफ़ॉर्म / आइडेंटिटी टीम | किल स्विच दबाते हैं, टोकन्स और ग्रांट्स रीवोक करते हैं, और लॉग्स सुरक्षित रखते हैं |
| डेटा प्रोटेक्शन / लीगल | यह तय करते हैं कि क्या पर्सनल डेटा प्रभावित हुआ था और किसे, क्या रिपोर्ट करना ज़रूरी है |
| कम्युनिकेशन्स | प्रभावित यूज़र्स, ग्राहकों या पार्टनर्स को स्पष्ट और सटीक मैसेज भेजकर सूचित करते हैं |
सबूत जो सिर्फ़ एजेंट सिस्टम्स में होते हैं
- आर्ग्युमेंट्स, रिज़ल्ट्स और एक्शन लेने वाले यूज़र के साथ टूल-कॉल लॉग्स।
- रन का पूरा कॉन्टेक्स्ट: सिस्टम प्रॉम्प्ट वर्ज़न, यूज़र मैसेजेस, हासिल किए गए डॉक्यूमेंट्स, टूल आउटपुट्स।
- मेमोरी और वेक्टर स्टोर का कॉन्टेंट, साथ ही यह जानकारी कि हर एंट्री कब और कहां से जोड़ी गई थी।
- इंसिडेंट के समय टूल के विवरण और सर्वर वर्ज़न्स (हो सकता है कि वे बाद में बदल गए हों)।
- मंज़ूरी (अप्रूवल) के रिकॉर्ड्स: किसने क्या मंज़ूर किया, और उन्हें क्या दिखाया गया था।
रिपोर्टिंग के नियम
टेबलटॉप एक्सरसाइज़
और देखें और पढ़ें
लैब
टाइमलाइन, फ़ैसलों और सुधारों की लिस्ट के साथ पूरी की गई एक टेबलटॉप एक्सरसाइज़।
समस्या
पाठ में दिए गए HR हेल्पडेस्क सिनेरियो (या अपने खुद के बनाए गए सिनेरियो) का इस्तेमाल करके, अकेले या 2-4 सहकर्मियों या क्लासमेट्स के साथ टेबलटॉप एक्सरसाइज़ करें। किसी भी असली सिस्टम को न छुएं।
- भूमिकाएं तय करें: इंसिडेंट लीड, एजेंट ओनर, प्लेटफ़ॉर्म टीम, डेटा प्रोटेक्शन, कम्युनिकेशन्स।
- प्लेबुक के हर कदम पर चर्चा करें। हर कदम के लिए फ़ैसला लिखें, यह कौन तय करता है, और इसमें वास्तव में कितना समय लगेगा।
- दिए गए समय पर स्टार्टर में दो "इन्जेक्ट्स" (अचानक आने वाली नई जानकारी) जोड़ें और तय करें कि आप क्या रिस्पॉन्स देंगे।
- आपको जो भी कमी मिली हो उसकी लिस्ट बनाएं (जैसे छूटे हुए लॉग्स, अस्पष्ट ओनर, किल स्विच न होना वगैरह)।
- कम से कम पाँच सुधार (fixes) लिखें, जिनमें से प्रत्येक का एक ओनर और तय तारीख हो।
TABLETOP: HR helpdesk agent gives staff an unknown link
T+0 min Three employees report the agent told them to "verify your salary account" at a link.
T+10 min INJECT 1: A fourth employee says they entered their details on that page.
T+30 min INJECT 2: The wiki history shows a contractor account edited the payroll FAQ page on Friday.
The same wiki is used by the IT helpdesk agent.
Questions to answer at each step:
- What do we switch off, and how?
- What evidence do we preserve, and where is it?
- Who else must know (inside and outside the company)?
- What do we tell staff, and when?आपका काम तब पूरा होगा जब
कठिन सवाल
उत्तर देखने से पहले ख़ुद जवाब देने की कोशिश करें। अगर आप इनके जवाब दे सकते हैं, तो आप पाठ समझ गए हैं।
Q1इन्जेक्ट 1 कहता है कि एक कर्मचारी ने अपनी डिटेल्स डाल दी हैं। इससे आपका रिस्पॉन्स कैसे बदल जाता है?दिखाएं
अब यह सिर्फ़ कॉन्टेंट की समस्या नहीं रही, बल्कि क्रेडेंशियल या पर्सनल डेटा से जुड़ा इंसिडेंट भी बन गया है। कर्मचारी को अपने अकाउंट्स सुरक्षित करने में मदद करें (पासवर्ड रीसेट, ज़रूरत पड़ने पर बैंक से संपर्क), जांचें कि क्या अन्य लोगों ने भी डिटेल्स दर्ज की हैं, रिपोर्टिंग से जुड़ी ज़िम्मेदारियों के लिए डेटा प्रोटेक्शन टीम को शामिल करें, और फ़िशिंग साइट की रिपोर्ट करने पर विचार करें। भारत में, अगर पैसों का जोखिम हो तो लोगों को cybercrime.gov.in या 1930 हेल्पलाइन पर भी भेजा जा सकता है।
Q2कॉन्ट्रैक्टर का अकाउंट एक मुख्य सुराग क्यों है, और आपको क्या मान लेने से बचना चाहिए?दिखाएं
यह दिखाता है कि पेज को किसने या किस चीज़ ने बदला, इसलिए यह एंट्री पॉइंट की तरफ इशारा करता है: हो सकता है अकाउंट compromised हो, उसका गलत इस्तेमाल हुआ हो, या किसी ऑटोमेटेड टूल ने उसका इस्तेमाल किया हो। यह मत मान लीजिए कि कॉन्ट्रैक्टर ही दोषी है; अक्सर अकाउंट्स पर किसी और का कब्ज़ा हो जाता है। अकाउंट को disable या reset करें, उसकी बाकी एक्टिविटी की जांच करें, और किसी नतीजे पर पहुँचने से पहले तथ्यों के साथ पड़ताल करें।
अक्सर पूछे जाने वाले सवाल
क्या हमें एजेंट को रोकने के बाद यह देखने के लिए रीस्टार्ट करना चाहिए कि क्या यह दोबारा होता है?
तब तक नहीं जब तक आप सबूत सुरक्षित न कर लें और पॉइज़न की गई मेमोरी, डॉक्यूमेंट्स या टूल के विवरणों की जांच न कर लें। रीस्टार्ट करने से नुकसान दोबारा हो सकता है और काम की पुरानी स्थिति (स्टेट) मिट सकती है। पहले जांच करें, फिर सख्त सीमाओं के साथ दोबारा इनेबल करें।
यह एक सामान्य सिक्योरिटी इंसिडेंट से किस तरह अलग है?
प्रक्रिया का ढांचा एक जैसा ही होता है। फ़र्क सबूतों (कॉन्टेक्स्ट, मेमोरी, टूल कॉल्स), वजह (अक्सर कोड नहीं, बल्कि टेक्स्ट) और रफ़्तार (एजेंट्स बहुत तेज़ी से और बड़े पैमाने पर काम करते हैं) में होता है। इसे आपकी सामान्य टीम को ही संभालना चाहिए, बस उसमें एजेंट ओनर को भी जोड़ लें।
हमें कितनी बार टेबलटॉप एक्सरसाइज़ करनी चाहिए?
नियमित रूप से, और जब भी आप कोई नया हाई-रिस्क एजेंट लॉन्च करें। कई टीमें एजेंट से जुड़े सिनेरियो को अपने मौजूदा एक्सरसाइज़ शेड्यूल में ही शामिल कर लेती हैं। हर एक्सरसाइज़ के आखिर में कमियों को ठीक करने वाले सुधारों और उनके ज़िम्मेदार लोगों की एक छोटी लिस्ट होनी चाहिए।
हमें प्रभावित यूज़र्स को क्या बताना चाहिए?
आसान शब्दों में बताएं कि क्या हुआ, कौन सा डेटा या कौन से एक्शन्स प्रभावित हुए, आपने क्या किया है, और उन्हें क्या करना चाहिए (उदाहरण के लिए, किसी मैसेज को नज़रअंदाज़ करना, पासवर्ड रीसेट करना)। बात सटीक रखें और अंदाज़ा लगाने से बचें। आपकी लीगल और कम्युनिकेशन्स टीमों को इसकी समीक्षा करनी चाहिए।
पाठ का टेस्ट
5 सवाल। पास होने और इस पाठ को पूरा करने के लिए 3 सही होने चाहिए (60%)।