ऑनलाइन सिग्नलों को Physical Event Risk से जोड़ना

एक ऐसा परिदृश्य जो ज़्यादातर सुरक्षा टीमें जितना मानना चाहेंगी, उससे कहीं ज़्यादा बार घटता है। एक एनालिस्ट किसी नामित executive को निशाना बनाती शत्रुतापूर्ण पोस्ट को फ़्लैग करता है। पोस्ट लॉग होती है, ticket खुलता है, और वह review queue में पड़ा रहता है। इसी बीच GSOC उस शाम executive के होटल से दो ब्लॉक दूर बन रहे एक विरोध-प्रदर्शन को ट्रैक कर रहा है। कोई दोनों को जोड़ता नहीं। Executive उस भीड़ में चला जाता है जिसमें मौजूद रहने का ऐलान ऑनलाइन कम से कम एक गुस्साया व्यक्ति पहले ही कर चुका है।

यह technology की विफलता नहीं है। यह workflow की विफलता है। और यह लगातार तब होती है जब डिजिटल निगरानी और physical event tracking अलग-अलग सिस्टमों में, ऐसी अलग-अलग टीमों के पास रहती हैं जो आपस में मुश्किल से बात करती हैं।

अलग-थलग निगरानी की समस्या

डिजिटल एनालिस्ट इरादा देखते हैं। वे देखते हैं कि कोई क्या कह रहा है, कितना गुस्से में है, भाषा escalate हो रही है या नहीं। जो वे आमतौर पर नहीं देखते, वह यह है कि वह व्यक्ति कहाँ है, principal के पास भौतिक रूप से क्या हो रहा है, या timing शेड्यूल की किसी चीज़ से मेल खाती है या नहीं।

GSOC टीमों की समस्या उलटी है। वे ज़मीन पर होता सब देखती हैं: विरोध-प्रदर्शनों के रूट, अपराध की घटनाएँ, यात्रा पर मौसम का असर, access control की घटनाएँ। जो उनके पास अक्सर नहीं होता, वह है यह context कि ऑनलाइन धमकियाँ कौन दे रहा है, कोई विशेष अकाउंट महीनों से executive पर fixate कर रहा है या नहीं, या venue के पास बन रही भीड़ में कोई ऐसा व्यक्ति है या नहीं जो नुकसान पहुँचाने की इच्छा खुलकर जता चुका है।

अकेले कोई भी दृश्य आत्मविश्वास से निर्णय लेने के लिए पर्याप्त नहीं है। पोस्ट देखने वाले एनालिस्ट को नहीं पता कि वह एक नाज़ुक क्षण में हो रही है। भीड़ देखने वाले GSOC operator को नहीं पता कि उसमें शामिल एक व्यक्ति हफ़्तों से ऑनलाइन escalate कर रहा है। इन दो तस्वीरों के बीच की खाई ही वह जगह है जहाँ घटनाएँ घटती हैं।

Industry research लगातार दिखाती आई है कि threat actors शायद ही कभी खुद को एक domain तक सीमित रखते हैं। जो लोग ऑनलाइन इरादा जताते हैं, वे नियमित रूप से भौतिक environments में सामने आते हैं। जो लोग आमने-सामने धमकाने वाला व्यवहार करते हैं, वे लगभग हमेशा एक डिजिटल निशान छोड़ते हैं। इन्हें अलग-अलग समस्याएँ मानना, अलग-अलग टीमों से, अलग-अलग डेटा के साथ निपटवाना — यही वह तरीका है जिससे संगठन उन चीज़ों पर सिर्फ़ प्रतिक्रिया करते रह जाते हैं जिन्हें उन्हें आते हुए देख लेना चाहिए था।

वास्तव में आपको क्या correlate करना है

आम प्रवृत्ति समस्या पर और डेटा फेंकने की होती है। और फ़ीड्स, और अलर्ट, और dashboards। यह जवाब नहीं है। बिना संरचना के ज़्यादा raw डेटा बस और तेज़ alert fatigue पैदा करता है।

आपको चाहिए एक फ्रेमवर्क, जो तय करे कि सिग्नलों के कौन से संयोजन मायने रखते हैं, और कब।

जानकारी की चार परतें एक ही समय पर, एक ही दृश्य में होनी चाहिए:

• Subject की गतिविधि: ऑनलाइन क्या कहा जा रहा है, कौन कह रहा है, और क्या वह escalate हो रहा है? इसमें सोशल प्लेटफ़ॉर्म, मैसेजिंग ऐप, डार्क वेब के स्रोत और ऐसे अकाउंट शामिल हैं जो पहले principal या संगठन पर fixate कर चुके हैं।
• Physical event का context: Principal की लोकेशन के पास अभी क्या हो रहा है? विरोध, प्रदर्शन, अपराध की घटनाएँ, ख़राब मौसम, infrastructure में व्यवधान, बड़े जमावड़े। इनमें से कोई भी ऑपरेशनल तस्वीर बदल देता है।
• Principal का context: Principal वास्तव में जा कहाँ रहा है? रूट, venues, होटल, खाने की जगहें, सार्वजनिक appearances, शेड्यूल में बदलाव। यही वह परत है जो बाकी सब कुछ को प्रासंगिक या अप्रासंगिक बनाती है।
• ऐतिहासिक व्यवहार: क्या यह subject पहले escalate कर चुका है? क्या अतीत में घटनाओं से पहले ऐसी ही परिस्थितियाँ रही हैं? यहाँ pattern recognition बेहद मायने रखती है और लगातार नज़रअंदाज़ होती है।

लक्ष्य यह सब अपने आप fuse कर देना नहीं है। लक्ष्य है एनालिस्ट्स को इतना overlap देना कि वे सही सवाल पूछ सकें: आस-पास भौतिक रूप से जो हो रहा है उसे देखते हुए, क्या यह ऑनलाइन सिग्नल और चिंताजनक हो जाता है?

Geofencing signal-to-noise अनुपात बदल देती है

डिजिटल और physical निगरानी को जोड़ने के सबसे व्यावहारिक औज़ारों में से एक है geofenced इंटेलिजेंस: venues, होटलों, transit रूटों और principal की नियमित लोकेशनों के चारों ओर भौगोलिक सीमाएँ तय करना, और फिर आने वाले सिग्नलों को इस आधार पर फ़िल्टर करना कि वे उन क्षेत्रों से उत्पन्न होते हैं या उनका संदर्भ देते हैं।

दस लाख की आबादी वाले शहर की कोई सामान्य सोशल मीडिया मॉनिटरिंग फ़ीड कंटेंट की विशाल मात्रा पैदा करती है, जिसका लगभग कोई भी हिस्सा आज रात जो हो रहा है उसके लिए ऑपरेशनली प्रासंगिक नहीं होता। होटल के चारों ओर और venue के दो-ब्लॉक के दायरे में geofenced फ़ीड उस मात्रा का एक छोटा-सा अंश पैदा करती है, और जो सामने आता है उसका कहीं बड़ा हिस्सा वाकई पढ़ने लायक होता है।

किसी विरोध-प्रदर्शन की staging location पर भौतिक रूप से मौजूद लोगों की पोस्ट गतिविधि के आधिकारिक रिपोर्टिंग चैनलों तक पहुँचने से 15 से 30 मिनट पहले आ सकती हैं। Principal के होटल के पास मौजूद किसी ऐसे व्यक्ति का location-tagged कंटेंट, जो ऑनलाइन शत्रुतापूर्ण कंटेंट भी पोस्ट करता रहा है, दोनों data points के अकेले होने की तुलना में बिल्कुल अलग तरह का सिग्नल है।

इसके काम करने के लिए AI classification को raw फ़ीड और एनालिस्ट के बीच बैठना होगा। इसके बिना, किसी बड़े इवेंट में geofenced फ़ीड भी इतनी मात्रा पैदा करती है जितनी इंसान रियल-टाइम में उपयोगी ढंग से review नहीं कर सकते। ऐसी classification जो physical security सिग्नलों को इवेंट की सामान्य गपशप, भीड़ के अपडेट और असंबंधित स्थानीय कंटेंट से अलग करे, फ़ीड को वास्तव में उपयोगी बनाती है।

Proximity बनने से पहले mobilization को कैसे पहचानें

ज़्यादातर threat assessment फ्रेमवर्क इस पर केंद्रित होते हैं कि कोई क्या कह रहा है। ज़्यादा कठिन और ज़्यादा अहम सवाल यह है कि क्या वह उसके बारे में कुछ कर रहा है।

Mobilization के संकेतक ही वह बदलाव हैं जिस पर आपकी नज़र होनी चाहिए। जो subject शिकायत जताने से आगे बढ़कर किसी विशिष्ट इवेंट, विशिष्ट तारीख या विशिष्ट स्थान का संदर्भ देने लगे, वह एक सार्थक रेखा पार कर चुका है। जो व्यक्ति principal के शेड्यूल के बारे में सवाल पूछता है, सार्वजनिक appearance की घोषणाओं पर प्रतिक्रिया देता है, या किसी साझा शिकायत के इर्द-गिर्द दूसरे अकाउंट्स के साथ तालमेल करता है — वह नियमित रूप से सिर्फ़ गुस्सा निकालने वाले व्यक्ति से अलग है।

यात्रा के सिग्नल भी मायने रखते हैं। एक शहर में रहने वाला subject अचानक उसी metro area में होने के बारे में पोस्ट करने लगे जहाँ executive की आगामी appearance है, वहाँ होने की कोई और स्पष्ट वजह न हो — तो उसे और ग़ौर से देखना चाहिए। यह तब ख़ास तौर पर सच है जब timing किसी सार्वजनिक रूप से घोषित इवेंट से मेल खाती हो।

इरादे से proximity की ओर बदलाव ही वह जगह है जहाँ वास्तविक दुनिया में संपर्क संभव हो जाता है। उसे पकड़ने के लिए ऑनलाइन व्यवहार का पैटर्न और principal कहाँ होगा — दोनों का physical context जानना ज़रूरी है। अकेला कोई भी टुकड़ा आपको वहाँ नहीं पहुँचाता।

Movement के निर्णय की समस्या

यहीं convergence अपनी असली क़ीमत साबित करती है। एक protection टीम principal को शहर से लेकर गुज़रने वाली है। रूट planned है। GSOC ने एक सड़क पर विरोध-प्रदर्शन फ़्लैग किया है। डिजिटल निगरानी ने उसी सामान्य क्षेत्र के अकाउंट्स से बढ़ी हुई दुश्मनी फ़्लैग की है। मौसम साफ़ है। विरोध अभी तक शांतिपूर्ण दिखता है।

क्या रूट पर आगे बढ़ना सुरक्षित है? क्या कोई वैकल्पिक रूट बेहतर है? क्या timing बदलनी चाहिए? क्या इस movement के लिए principal को अतिरिक्त coverage चाहिए?

इनमें से कोई भी सवाल किसी एक data stream से आत्मविश्वास के साथ नहीं सुलझ सकता। आपको चाहिए — विरोध की लोकेशन और अनुमानित आकार, ऑनलाइन चर्चा का लहजा और रुख़, principal का शेड्यूल और उसमें वास्तविक रूप से कितनी लचक है, और कुछ अंदाज़ा कि यह स्थिति पहले की उन स्थितियों से मिलती है या नहीं जो escalate हुई थीं या नहीं हुई थीं।

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

जो टीमें दोनों को एक एकीकृत प्लेटफ़ॉर्म में चलाती हैं, वे उस पुनर्निर्माण के कदम के बिना "दिलचस्प सिग्नल" से सीधे "आज रात की movement plan के लिए इसका यह मतलब है" तक पहुँच जाती हैं। यह कोई छोटी-मोटी efficiency की बढ़त नहीं है। जिन परिदृश्यों में timing मायने रखती है, वहाँ यही सुरक्षात्मक कार्रवाई और प्रतिक्रियात्मक जवाब के बीच का फ़र्क़ है।

ऐसे indicators और warnings बनाना जो वाकई काम करें

GSOCs जिस चीज़ में लगातार कम निवेश करते हैं, वह है अपने principal की profile और operating environment के हिसाब से परिभाषित indicators और warnings का एक सेट बनाना। ज़्यादातर संगठन अपने सामने खड़े वास्तविक खतरों के अनुरूप intelligence requirements बनाने के बजाय generic alert thresholds से काम चला लेते हैं।

Priority intelligence requirements (PIRs) एक सैन्य अवधारणा है जो कॉर्पोरेट protective intelligence में अच्छी तरह उतरती है। PIR यह पहचानती है कि निर्णय लेने के लिए आपको विशेष रूप से क्या जानना ज़रूरी है — बजाय इसके कि सब कुछ मोटे तौर पर मॉनिटर करते रहें और उम्मीद करें कि कुछ प्रासंगिक सामने आ जाएगा। Executive protection के लिए PIR यह परिभाषित कर सकती है: कौन से ऑनलाइन व्यवहार, किन physical संकेतकों के साथ मिलकर, रूट बदलने की माँग करेंगे? सिग्नलों का कौन-सा संयोजन एक अतिरिक्त advance agent ट्रिगर करेगा? किस बात पर क़ानून प्रवर्तन को सूचित करना उचित होगा?

जब ये thresholds पहले से तय हों और ऐसी data फ़ीड्स से जुड़े हों जो वाकई सही सिग्नल सामने ला सकें, तो दबाव में निर्णय की प्रक्रिया नाटकीय रूप से तेज़ हो जाती है। एनालिस्ट उस क्षण में कुछ गढ़ नहीं रहे होते। वे जो देख रहे हैं उसे एक ऐसे फ्रेमवर्क से मिला रहे होते हैं जिस पर वे पहले ही सहमत हो चुके हैं।

व्यवहार में cross-domain integration असल में कैसी दिखती है

जब डिजिटल और physical इंटेलिजेंस सचमुच converge होती हैं, तो कुछ चीज़ें संभव हो जाती हैं जो अन्यथा संभव नहीं हैं।

Threat actor की profiles रियल-टाइम में समृद्ध हो सकती हैं। छह महीने से monitoring queue में पड़ा कोई ऑनलाइन subject उसी क्षण ऑपरेशनली प्रासंगिक हो जाता है जब उसकी लोकेशन principal के शेड्यूल से overlap करती है। Integration के बिना वह कड़ी घंटों देर से जुड़ती है, या कभी जुड़ती ही नहीं।

False positives घटते हैं, क्योंकि context उन्हें छान देता है। जो शत्रुतापूर्ण पोस्ट अकेले देखने पर चिंताजनक लगती है, वह तब अलग दिखती है जब principal के आस-पास का भौतिक माहौल शांत हो और subject में mobilization का कोई संकेत न हो। Context हमेशा चीज़ों को escalate नहीं करता। कभी-कभी वह de-escalate करता है, जो principal के शेड्यूल में अनावश्यक व्यवधान से बचने की कोशिश कर रही टीम के लिए उतना ही मूल्यवान है।

Post-incident विश्लेषण बेहतर होता है। जब सब कुछ एक ही सिस्टम में हो, तो आप पीछे मुड़कर देख सकते हैं कि किसी घटना से पहले कौन से सिग्नल मौजूद थे और पैटर्न कैसा दिखता था। इसी तरह आप समय के साथ अपने indicators और warnings को tune करते हैं — बजाय इसके कि वही सामान्य निगरानी अनिश्चित काल तक चलाते रहें।

असली समस्या workflow की खाई है

Converged डिजिटल-physical निगरानी की technology मौजूद है। ऐसे प्लेटफ़ॉर्म, जो सोशल इंटेलिजेंस, इवेंट फ़ीड्स, geofenced डेटा और principal के context को एक एकीकृत दृश्य में लाते हैं, उपलब्ध हैं और उन संगठनों में तैनात हैं जो इसे गंभीरता से लेते हैं।

जिसे ठीक करना कठिन है, वह है workflow की खाई। डिजिटल और physical security टीमें अक्सर संगठन के अलग-अलग हिस्सों को रिपोर्ट करती हैं, अलग-अलग टूल इस्तेमाल करती हैं, और उनकी operating रफ़्तार अलग होती है। Intelligence एनालिस्ट्स और protective agents के पास इस बारे में हमेशा साझा शब्दावली नहीं होती कि credible threat किसे माना जाए। तेज़ी से बदलती स्थिति में टीमों के बीच handoffs ही वह जगह है जहाँ context खो जाता है।

Convergence सिर्फ़ technology का निर्णय नहीं है। यह एक ऑपरेशनल निर्णय है। इसके लिए पहले से परिभाषित करना ज़रूरी है कि cross-domain escalation किस टीम के ज़िम्मे है, जब कोई सिग्नल डिजिटल और physical दोनों domains में फैला हो तो notification का रास्ता कैसा होगा, और response फ्रेमवर्क का हर स्तर किन कार्रवाइयों को अधिकृत करता है।

Workflow सही कर लीजिए, तो technology बहुत ताक़तवर हो जाती है। Workflow टूटा छोड़ दीजिए, तो बेहतरीन प्लेटफ़ॉर्म भी सिर्फ़ ऐसे अलर्ट सामने लाता रहेगा जिन पर समय रहते कोई कार्रवाई नहीं करता।