72 मिनट की ब्रीच विंडो का सुरक्षा टीमों के लिए वास्तव में क्या मतलब है

कुछ हमलावर शुरुआती पहुँच से लेकर डेटा चोरी तक एक घंटे से कुछ ही ज़्यादा समय में पहुँच सकते हैं। इसका मतलब यह नहीं है कि हर ब्रीच एक ही घड़ी पर चलता है — या हर प्रतिक्रिया को स्वचालित होना चाहिए।

एक सुरक्षा टीम को अलर्ट मिलता है कि किसी उपयोगकर्ता ने किसी असामान्य स्थान से साइन-इन किया है। एक विश्लेषक केस खोलता है, खाते का इतिहास जाँचता है और कर्मचारी से संपर्क करना शुरू करता है।

यह जाँच चल ही रही होती है कि हमलावर चुराए गए सेशन का इस्तेमाल कर एक जुड़े हुए SaaS ऐप्लिकेशन में घुस जाता है, एक क्लाउड क्रेडेंशियल ढूँढता है और डेटा जुटाना शुरू कर देता है। जब तक टीम पहले अलर्ट की पुष्टि करती है, तब तक जानकारी वातावरण से बाहर जा चुकी होती है।

2026 के एक व्यापक रूप से दोहराए गए आँकड़े के पीछे यही परिचालन समस्या है: Palo Alto Networks Unit 42 द्वारा जाँचे गए सबसे तेज़ मामलों में, हमलावर शुरुआती पहुँच से डेटा एक्सफ़िल्ट्रेशन तक 72 मिनट में पहुँच गए।

यह आँकड़ा ध्यान देने लायक़ है। इसे संदर्भ भी चाहिए। यह एक इंसिडेंट-रिस्पॉन्स डेटासेट में सबसे तेज़ देखी गई श्रेणी थी, हर आधुनिक ब्रीच की औसत अवधि नहीं। इसका मतलब यह नहीं है कि हर हमला किसी स्वायत्त AI एजेंट से चलाया जा रहा है, या हर संगठन को हर अलर्ट ठीक 72 मिनट में रोकना ही होगा।

उपयोगी सबक सीधा है: कुछ घुसपैठ अब क्यू, मैनुअल हैंडऑफ़ और बिखरे हुए सबूतों पर बनी किसी रिस्पॉन्स प्रक्रिया से तेज़ चल सकती हैं।

सुरक्षा रिपोर्टें अलग-अलग घड़ियाँ माप रही हैं

2026 की कई ख़तरा रिपोर्टें पूरी तरह अलग हक़ीक़तों का वर्णन करती दिखती हैं।

रिपोर्ट किया गया माप	2026 का आँकड़ा	घड़ी क्या मापती है
तेज़ शुरुआती पहुँच से डेटा एक्सफ़िल्ट्रेशन तक	72 मिनट	वातावरण में प्रवेश से लेकर डेटा के बाहर जाना शुरू होने तक
औसत eCrime ब्रेकआउट समय	29 मिनट	एक सिस्टम में प्रवेश से लेकर लेटरल मूवमेंट शुरू होने तक
सबसे तेज़ देखा गया eCrime ब्रेकआउट	27 सेकंड	लेटरल मूवमेंट का एक चरम उदाहरण, सामान्य रिस्पॉन्स लक्ष्य नहीं
वैश्विक मीडियन डवेल टाइम	14 दिन	वातावरण में प्रवेश से लेकर घुसपैठ का पता चलने तक

Unit 42 ने अपने निष्कर्ष 50 से ज़्यादा देशों में 750 से अधिक बड़ी घटनाओं के आधार पर निकाले। CrowdStrike ने अलग से बताया कि औसत eCrime ब्रेकआउट समय घटकर 29 मिनट रह गया है, जिसमें एक चरम मामला 27 सेकंड में ब्रेकआउट तक पहुँचा। Mandiant ने 14 दिन का वैश्विक मीडियन डवेल टाइम बताया।

ये आँकड़े सीधे तुलनीय नहीं हैं। ये अलग-अलग प्रोवाइडरों, ग्राहक-समूहों और परिभाषाओं से आते हैं। एक प्रवेश के बाद की गतिविधि मापता है। दूसरा डेटा चोरी की दिशा में प्रगति मापता है। डवेल टाइम मापता है कि हमलावर कितनी देर तक बिना पकड़ में आए रहता है।

सुरक्षा नेताओं को किसी एक आँकड़े को सार्वभौमिक उलटी गिनती में बदलने से बचना चाहिए।

तेज़ और धीमे हमले एक साथ मौजूद हो सकते हैं

एक आर्थिक रूप से प्रेरित हमलावर के पास पहले से काम कर रहे क्रेडेंशियल और साफ़ लक्ष्य हो सकते हैं। हफ़्तों तक छिपे रहने की कोई ख़ास वजह नहीं होती। हमलावर प्रवेश कर सकता है, पहुँच बढ़ा सकता है, जानकारी जुटा सकता है और जबरन वसूली शुरू कर सकता है, जबकि पीड़ित अभी यह तय ही कर रहा होता है कि पहला अलर्ट गंभीर है या नहीं।

एक जासूसी करने वाले हमलावर का मक़सद अलग होता है। वह चुपचाप बना रह सकता है, वैध प्रशासनिक टूल इस्तेमाल कर सकता है और धीरे-धीरे जानकारी तक पहुँच सकता है। Mandiant की 2026 की रिपोर्टिंग में जासूसी और उत्तर कोरियाई IT-वर्कर मामलों में कहीं लंबे डवेल टाइम पाए गए। कुछ अभियान कई महीनों तक छिपे रहे।

इन दोनों पैटर्न के लिए अलग-अलग ताक़तें चाहिए:

• तेज़ हमलों के लिए शुरुआती संकेत और पहले से अधिकृत कंटेनमेंट चाहिए।
• धीमे हमलों के लिए टिकाऊ लॉग, थ्रेट हंटिंग और समय के साथ व्यवहार में झलकने वाली दृश्यता चाहिए।

कोई संगठन एक पर सुधार कर सकता है और दूसरे में कमज़ोर रह सकता है। अगर शुरुआती गतिविधि कभी दिखे ही नहीं, तो तेज़ स्वचालित प्रतिक्रिया मदद नहीं करती। अगर कोई तेज़ घुसपैठ संवेदनशील डेटा तक पहुँचने से पहले कोई कार्रवाई ही नहीं कर पाता, तो लंबा लॉग रिटेंशन मदद नहीं करता।

AI जाना-पहचाना काम तेज़ कर रहा है

अब तक के सबूत नए तरह के हमलों की तुलना में तेज़ी की ओर ज़्यादा इशारा करते हैं।

Unit 42 का कहना है कि उसने AI को टोही, फ़िशिंग, स्क्रिप्टिंग और परिचालन निष्पादन के लिए इस्तेमाल होते देखा है। Sophos ने एक ऐसे अभियान का दस्तावेज़ीकरण किया जिसमें लगभग 12 AI एजेंट का इस्तेमाल कर लगभग 80 हानिकारक मॉड्यूल और 70 से ज़्यादा इवेज़न तकनीकें विकसित और परखी गईं। जो काम किसी व्यक्ति को हफ़्तों में पूरा करना पड़ता, वह दिनों में पूरा हो गया।

ये अहम घटनाक्रम हैं, पर अंतर्निहित गतिविधियाँ जानी-पहचानी ही रहती हैं: पहुँच हासिल करना, नियंत्रणों से बचना, सिस्टम में घूमना और जानकारी चुराना। AI किसी हमलावर को इस काम का कुछ हिस्सा तेज़ी और बड़े पैमाने पर करने में मदद कर सकता है। यह क्रेडेंशियल, पहुँच योग्य सिस्टम या लक्ष्य तक रास्ते की ज़रूरत ख़त्म नहीं करता।

यह फ़र्क़ इसलिए मायने रखता है क्योंकि इससे रक्षात्मक प्रतिक्रिया व्यावहारिक बनी रहती है। टीमों को “AI हमलों” के लिए बिल्कुल नए सुरक्षा कार्यक्रम की ज़रूरत नहीं है। उन्हें पहचान, दृश्यता और प्रतिक्रिया के उन अंतरों को बंद करना है जिनका फ़ायदा तेज़ स्वचालन उठा सकता है।

पहचान और जुड़ी हुई सेवाएँ प्रतिक्रिया को बदल देती हैं

Unit 42 की रिपोर्ट है कि उसकी लगभग 90% जाँचों में पहचान संबंधी कमज़ोरियों की महत्वपूर्ण भूमिका रही। लगभग 48% में ब्राउज़र गतिविधि शामिल थी, जबकि 23% में तीसरे-पक्ष के SaaS ऐप्लिकेशन शामिल थे।

इसलिए किसी लैपटॉप को अलग-थलग करने के बाद भी कोई घटना जारी रह सकती है। चुराया गया ब्राउज़र सेशन अभी भी सक्रिय हो सकता है। कोई OAuth ग्रांट ईमेल या क्लाउड स्टोरेज तक पहुँच दे सकता है। कोई समझौता किया गया सर्विस अकाउंट बिना इंटरैक्टिव लॉगिन के भी काम कर सकता है। मूल उपयोगकर्ता का पासवर्ड बदलने के बाद भी कोई तीसरे-पक्ष का इंटीग्रेशन भरोसेमंद बना रह सकता है।

एक आधुनिक कंटेनमेंट योजना यह करने में सक्षम होनी चाहिए:

• सक्रिय सेशन और रिफ़्रेश टोकन रद्द करना;
• संदिग्ध OAuth ग्रांट अक्षम करना;
• उजागर हुई API कुंजियाँ और सर्विस क्रेडेंशियल बदलना;
• फ़िशिंग-प्रतिरोधी पुनः-प्रमाणीकरण करवाना;
• इनबॉक्स नियमों और प्रतिनिधि पहुँच की जाँच करना;
• क्लाउड भूमिकाएँ और अस्थायी क्रेडेंशियल सीमित करना;
• प्रभावित एंडपॉइंट को अलग-थलग करना; और
• उन जुड़े SaaS ऐप्लिकेशन की पहचान करना जिन्हें पहुँच विरासत में मिली।

एंडपॉइंट, पहचान, ब्राउज़र, ईमेल, क्लाउड और SaaS के सबूत एक ही जाँच में एक साथ आने चाहिए। अगर हर टीम सिर्फ़ अपना उत्पाद देखती है, तो हैंडऑफ़ का फ़ायदा हमलावर को मिलता है।

पहले 72 मिनट

हमले की गति एक सार्वभौमिक घड़ी नहीं है। किसी संभावित संकेत, वह कहाँ दिखेगा, सिस्टम सुरक्षित रूप से क्या स्वचालित कर सकता है, और कहाँ किसी व्यक्ति को अब भी फ़ैसला लेना होगा — यह देखने के लिए नीचे कोई चरण चुनें। उदाहरण टॉगल एक उदाहरणात्मक तेज़ घुसपैठ की तुलना एक धीमी, ज़्यादा गुप्त घुसपैठ से करता है — दोनों शिक्षाप्रद परिदृश्य हैं, मापे गए औसत नहीं।

स्वचालन को संभावित नुक़सान पर निर्भर होना चाहिए

“स्वचालित करो या पीछे रह जाओ” सुनने में निर्णायक लगता है, पर यह अधूरी सलाह है। कोई ग़लत सकारात्मक जो किसी अलर्ट को समृद्ध करता है, बहुत कम नुक़सान करता है। कोई ग़लत सकारात्मक जो किसी साझा प्रोडक्शन पहचान को अक्षम कर देता है, आउटेज पैदा कर सकता है।

स्वचालन का सही स्तर पहचान के भरोसे, पलटाव-क्षमता, असर के दायरे और व्यावसायिक महत्व पर निर्भर करता है।

प्रतिक्रिया कार्रवाई	उचित व्यवहार
किसी अलर्ट में पहचान, एंडपॉइंट और ख़तरा संदर्भ जोड़ना	स्वचालित करें
किसी पुष्ट हानिकारक संकेतक को अस्थायी रूप से ब्लॉक करना	एक्सपायरी और रोलबैक के साथ स्वचालित करें
स्पष्ट रूप से संदिग्ध किसी एक ब्राउज़र या OAuth सेशन को रद्द करना	जब भरोसा ज़्यादा हो तो स्वचालित करें
किसी सामान्य कर्मचारी वर्कस्टेशन को अलग-थलग करना	तेज़ पलटाव के साथ सशर्त स्वचालन
किसी प्रिविलेज्ड या साझा खाते को अक्षम करना	बारीक़ी से परखे गए आपातकालीन नियम के अलावा मानव मंज़ूरी
किसी प्रोडक्शन सर्वर को अलग-थलग करना	इंसिडेंट कमांडर या सेवा-स्वामी की मंज़ूरी
किसी क्लाउड वर्कलोड या डेटा को हटाना	पहली कंटेनमेंट कार्रवाई के रूप में कभी इस्तेमाल न करें
किसी ग्राहक-सम्मुख सेवा को बंद करना	व्यावसायिक-असर आकलन के साथ मानव मंज़ूरी

यह कोई सार्वभौमिक नीति तालिका नहीं है। हर संगठन को इसे अपने सिस्टम और नियामक दायित्वों के अनुसार बदलना होगा। सिद्धांत टिकाऊ है: उन कार्रवाइयों को स्वचालित करें जो अच्छी तरह समझी गई, सीमित और पलटी जा सकने वाली हैं। बड़े या अनिश्चित असर-दायरे वाली कार्रवाइयों से पहले मानव मंज़ूरी रखें।

स्वचालन को सबूत भी सुरक्षित रखने चाहिए। मैलवेयर हटाने से हमलावर के प्रवेश के तरीक़े को समझने के लिए ज़रूरी जानकारी नष्ट हो सकती है। किसी वर्कलोड को हटाने से लॉग या अस्थायी स्थिति खो सकती है। कंटेनमेंट का मक़सद आगे के नुक़सान को रोकना है, जबकि जाँच और रिकवरी का रास्ता खुला रखना है।

एक MTTR आँकड़े की जगह एक प्रतिक्रिया शृंखला अपनाएँ

औसत प्रतिक्रिया समय, या MTTR, अक्सर सुरक्षा प्रदर्शन के एक अकेले माप के रूप में पेश किया जाता है। यह छिपा सकता है कि देरी कहाँ हुई।

एक ज़्यादा उपयोगी प्रतिक्रिया शृंखला यह दर्ज करती है:

1. पहले भरोसेमंद संकेत तक का समय: संगठन को कार्रवाई का समर्थन करने वाला सबूत पहली बार कब मिला?
2. स्वामित्व तक का समय: किसी व्यक्ति या स्वचालित वर्कफ़्लो ने ज़िम्मेदारी स्वीकार करने में कितना समय लिया?
3. दायरा समझने तक का समय: टीम को प्रभावित पहचान, सिस्टम और सेवाएँ पहचानने में कितना समय लगा?
4. कंटेनमेंट तक का समय: हमलावर की जारी रखने की क्षमता कब भौतिक रूप से सीमित हुई?
5. कंटेनमेंट सत्यापित करने तक का समय: स्वतंत्र सबूत ने कब दिखाया कि हानिकारक गतिविधि रुक गई है?
6. रिकवरी तक का समय: सेवाएँ किसी भरोसेमंद परिचालन स्थिति में कब लौटीं?

सिर्फ़ औसत नहीं, बल्कि मीडियन और धीमे पर्सेंटाइल भी मापें। एक अच्छा औसत उन कुछ घटनाओं को छिपा सकता है जो घंटों तक बिना किसी स्वामी के पड़ी रहती हैं। ग़लत-कंटेनमेंट दर और रोलबैक समय भी ट्रैक करें; तेज़ कार्रवाई कोई सुधार नहीं है अगर वह बार-बार वैध काम में रुकावट डालती है।

तैयारी घटना से पहले ही रफ़्तार पैदा करती है

किसी घटना का पहला घंटा यह तय करने का बुरा समय है कि कोई खाता अक्षम करने या किसी सर्वर को अलग-थलग करने का अधिकार किसके पास है।

NIST का मौजूदा इंसिडेंट-रिस्पॉन्स मार्गदर्शन तैयारी, प्रतिक्रिया और रिकवरी को संगठन के व्यापक साइबर-सुरक्षा जोखिम प्रबंधन के भीतर रखता है। कनाडा का साइबर सेंटर भी घटनाओं का पता लगाने, प्रतिक्रिया देने और उनसे उबरने के लिए दस्तावेज़ीकृत प्रक्रियाओं की सिफ़ारिश करता है।

अलर्ट आने से पहले टीमों को तय कर लेना चाहिए:

• पहचान, एंडपॉइंट, क्लाउड और SaaS कंटेनमेंट किसके अधिकार में है;
• कौन-से सिस्टम और पहचान स्वचालित आइसोलेशन के लिए बहुत महत्वपूर्ण हैं;
• कौन-सी प्रतिक्रिया कार्रवाइयाँ पहले से अधिकृत हैं;
• कार्रवाइयों को कैसे पलटा जाता है;
• आपातकालीन पहुँच कहाँ रखी जाती है;
• कौन-से सबूत सुरक्षित रखे जाने चाहिए;
• संबंधित लॉग कितने समय तक उपलब्ध रहते हैं; और
• क़ानूनी, गोपनीयता, संचार और व्यावसायिक नेताओं को कब शामिल होना चाहिए।

यथार्थवादी टाइमलाइन के साथ अभ्यास चलाएँ। किसी संदिग्ध लॉगिन से शुरुआत करें और ईमेल, ब्राउज़र, SaaS और क्लाउड सिस्टम में नए सबूत जोड़ते जाएँ। मापें कि हर जगह उसी पहचान को ढूँढने, उसके सेशन रद्द करने और डेटा मूवमेंट रुकने की पुष्टि करने में कितना समय लगता है।

अभ्यास को डिटेक्शन टूल जितना ही फ़ैसला लेने के अधिकारों की भी परख करनी चाहिए। किसी तकनीकी रूप से सही अलर्ट की क़ीमत सीमित होती है जब किसी को पता ही न हो कि उस पर कार्रवाई कौन कर सकता है।

72-मिनट के निष्कर्ष से क्या बदलना चाहिए

72-मिनट वाला मामला कोई सार्वभौमिक समय-सीमा तय नहीं करता। यह उन प्रतिक्रिया मॉडलों की कमज़ोरी उजागर करता है जो यह मान लेते हैं कि जाँचकर्ताओं के पास फ़ैसला लेने से पहले सबूत जुटाने के लिए हमेशा कई घंटे होंगे।

सुरक्षा टीमों को इसका इस्तेमाल चार सवाल पूछने के लिए करना चाहिए:

• क्या हम पहचान, एंडपॉइंट, ब्राउज़र, क्लाउड और SaaS गतिविधि को तेज़ी से जोड़ सकते हैं?
• कौन-सी उच्च-भरोसे वाली कंटेनमेंट कार्रवाइयाँ पहले से अधिकृत हैं?
• क्या हर स्वचालित कार्रवाई की व्याख्या की जा सकती है और उसे पलटा जा सकता है?
• क्या हम सत्यापित कर सकते हैं कि कंटेनमेंट ने वाक़ई हमलावर को रोक दिया?

मक़सद इंसिडेंट रिस्पॉन्स से लोगों को हटाना नहीं है। मक़सद है लोगों को अनिश्चित, उच्च-असर वाले फ़ैसलों पर केंद्रित रखना, जबकि मशीनें सबूत जुटाएँ और स्थिति की माँग के अनुसार, सीमित दायरे वाली कार्रवाइयाँ उसी रफ़्तार से करें।

कुछ हमलावर मिनटों में आगे बढ़ सकते हैं। कुछ महीनों तक छिपे रह सकते हैं। एक परिपक्व सुरक्षा संचालन को दोनों घड़ियों के लिए तैयार रहना चाहिए।

संबंधित पठन: फ्रंटियर साइबर-सुरक्षा AI ट्रस्टेड-एक्सेस गेट्स के पीछे क्यों जा रहा है, DNS सर्वर उच्च-मूल्य वाला हमला लक्ष्य क्यों बने रहते हैं, और 2026 के रैनसमवेयर आँकड़े सुरक्षा टीमों को वाक़ई क्या बताते हैं.

संदर्भ और आगे पढ़ने के लिए

• 2026 Unit 42 Global Incident Response Report — Attacks Now 4x Faster — Palo Alto Networks Unit 42, 17 फ़रवरी 2026. 72-मिनट वाले अवलोकन और पहचान, ब्राउज़र, SaaS तथा बहु-सतह घटनाओं को कवर करने वाले निष्कर्षों का स्रोत।
• 2026 Global Threat Report — CrowdStrike, 2026. औसत और सबसे तेज़ देखे गए eCrime ब्रेकआउट समय तथा AI-सक्षम विरोधी गतिविधि की रिपोर्ट देता है।
• M-Trends 2026 — Google Cloud/Mandiant, 23 मार्च 2026. वैश्विक मीडियन डवेल टाइम और लंबे समय तक चलने वाले घुसपैठ पैटर्न की रिपोर्ट देता है।
• AI Is Compressing Cyberattack Timelines — Sophos, जुलाई 2026. STAC6994 अभियान और AI पहचानों तथा जुड़ी सेवाओं से जुड़े उभरते जोखिमों का वर्णन करता है।
• NIST SP 800-61 Revision 3: Incident Response Recommendations and Considerations — National Institute of Standards and Technology, अप्रैल 2025. NIST Cybersecurity Framework 2.0 के अनुरूप मौजूदा इंसिडेंट-रिस्पॉन्स मार्गदर्शन।
• Developing your incident response plan — Canadian Centre for Cyber Security, जनवरी 2026 में समीक्षित। डिटेक्शन, प्रतिक्रिया और रिकवरी प्रक्रियाएँ तैयार करने के लिए व्यावहारिक मार्गदर्शन।

स्रोत समीक्षा तिथि: 25 सितंबर 2026.