Multi-Layer Correlation कैंपेन डिटेक्शन कैसे काम करता है #
क्रॉस-लेयर ट्रेसिंग के ज़रिए उन अटैक परिदृश्यों को विज़ुअलाइज़ करना जो सिंगल-डिवाइस लॉग में दिखाई नहीं देते
1. परिचय — “सिंगल-डिवाइस लॉग” पर्याप्त क्यों नहीं हैं #
सिक्योरिटी लॉग मॉनिटरिंग ऑपरेशंस में, “कोई विशेष IP address संदिग्ध है” जैसे निर्णय आमतौर पर प्रत्येक डिवाइस के लॉग से स्वतंत्र रूप से लिए जाते हैं।
- FW पर कई पोर्ट स्कैन हो रहे हैं → Block
- वेब सर्वर पर vulnerability स्कैन आ रहे हैं → Alert
- VPN authentication कई बार फेल हो रहा है → अकाउंट लॉक
हर डिवाइस अपने-अपने स्तर पर निर्णय लेती है। यही स्टैंडर्ड ऑपरेशंस है।
लेकिन असली अटैक कहीं ज़्यादा संगठित होते हैं और एक समन्वित परिदृश्य के तहत कई लेयर्स में फैलकर काम करते हैं।
उदाहरण के लिए, मान लीजिए कोई अटैकर नीचे दिए क्रम में घुसपैठ की कोशिश करता है।
1. Reconnaissance via FW (port scan) ← L1 Network Layer
2. Vulnerability scan on public web port ← L4 Application Layer
3. Brute force against SSH or VPN ← L3 Authentication Layer
4. After intrusion, lateral movement in internal network ← L5 Endpoint Layerअगर हर डिवाइस इसे अलग-अलग डिटेक्ट करे, तो हर घटना महज़ “थोड़ा संदिग्ध, अलग-थलग व्यवहार” दिखती है। FW टीम सोचती है “बस एक और रूटीन स्कैन है,” वेब सर्वर टीम सोचती है “बस एक और स्कैनर है,” और VPN टीम सोचती है “एक और brute force प्रयास है,” और सब अलग-अलग रिस्पॉन्ड करते हैं।
जबकि ये चारों गतिविधियाँ एक ही अटैकर की लगातार की गई कार्रवाइयाँ हैं। जब इन्हें एक सतत परिदृश्य के रूप में देखा जाता है, तो रिस्पॉन्स प्राथमिकता, ब्लॉकिंग का दायरा और अलर्ट लेवल — सब नाटकीय रूप से बदल जाते हैं।
BASTION का multi-layer correlation कैंपेन डिटेक्शन एक ऐसा तंत्र है जो “एक ही IP को धुरी बनाकर, कई डिवाइसों के अलग-अलग डिटेक्शन को समय और लेयर्स के आर-पार एक-दूसरे पर सुपरइम्पोज़ करता है”। इस लेख में मैं इसके डिज़ाइन दर्शन और तंत्र की व्याख्या करूँगा, हमारी पेटेंट फाइलिंग (2026) के अंतर्गत आने वाले गणितीय सूत्रों को छोड़कर।
2. “लेयर” की अवधारणा — लॉग को पाँच दृष्टिकोणों से व्यवस्थित करना #
BASTION लॉग को नीचे दी गई पाँच “लेयर्स” में व्यवस्थित करता है।
| लेयर | दृष्टिकोण | प्रतिनिधि लॉग सोर्स |
|---|---|---|
| L1 नेटवर्क लेयर | पैकेट-स्तर का व्यवहार | FW, IDS/IPS |
| L2 कम्युनिकेशन पाथ लेयर | VPN/लोड बैलेंसर आदि | OpenVPN, HAProxy |
| L3 ऑथेंटिकेशन लेयर | Authentication की सफलता/विफलता | Active Directory, SSH, वेब एप्लिकेशन authentication |
| L4 एप्लिकेशन लेयर | Web/API एक्सेस | Apache, Nginx, IIS |
| L5 एंडपॉइंट लेयर | डिवाइस/सर्वर के भीतर का व्यवहार | Windows Event Log, auditd |
यह लेयर वर्गीकरण कोई यांत्रिक डिवाइस वर्गीकरण नहीं, बल्कि “अटैक की प्रगति के चरणों” से मैप होने वाला वर्गीकरण है। L1 में reconnaissance, L2 में पाथ की खोजबीन, L3 में authentication का भेदन, L4 में एप्लिकेशन की vulnerabilities, और L5 में आंतरिक गतिविधि आती है। आम तौर पर, अटैक की प्रगति इन लेयर्स में ऊपर की ओर बढ़ती है।
यह तथ्य कि “कोई विशेष अटैक IP कई लेयर्स में देखा जा रहा है”, इस बात का एक मज़बूत संकेतक है कि “अटैक अगले चरण की ओर बढ़ रहा है”।
3. trace-registry — IP के आधार पर क्रॉस-लेयर ऑब्ज़र्वेशन स्थिति को एकत्रित करना #
प्रत्येक डिवाइस के लॉग एनालिसिस के दौरान, BASTION यह जमा करता रहता है कि “यह IP कब, किस लेयर पर, और कितनी बार देखा गया”। इसे trace-registry कहा जाता है।
अवधारणात्मक रूप से, इसकी संरचना ऐसी दिखती है (वास्तविक वैल्यू सैंपल हैं)।
{
"traces": {
"203.0.113.42": {
"layers": {
"L1_network": {
"first_seen": "2026-05-10T13:01:23+09:00",
"last_seen": "2026-05-10T13:42:11+09:00",
"count": 47,
"context": ["FW block: port_scan", "FW block: ssh_attempt"]
},
"L4_app": {
"first_seen": "2026-05-10T13:35:08+09:00",
"last_seen": "2026-05-10T13:41:55+09:00",
"count": 12,
"context": ["webserver 404: vuln_scan", "webserver 403: forbidden_path"]
}
},
"layer_count": 2,
"total_count": 59
}
}
}इस संरचना की मुख्य बात यह है कि यह “डिवाइस” के बजाय “लेयर” के आधार पर एकत्रीकरण करती है। यदि कई FW यूनिट मौजूद हों, तो उन सभी को L1 नेटवर्क लेयर माना जाता है। इसके विपरीत, यदि एक ही सर्वर Apache (L4) और auditd (L5) दोनों के लॉग निकालता है, तो इसे दो लेयर्स से आए सिग्नल माना जाता है।
इसके अलावा, हर लेयर के ऑब्ज़र्वेशन टाइम-एक्सिस के साथ इतनी बारीकी (granularity) पर रिकॉर्ड किए जाते हैं कि अटैक की प्रगति पढ़ी जा सके।
4. Coherence फ़ंक्शन — “क्रॉस-लेयर समन्वय” का परिमाणीकरण #
अब हम BASTION के मर्म तक पहुँचते हैं।
सिर्फ़ यह तथ्य कि “कोई IP कई लेयर्स में देखा गया है” अपने आप में कैंपेन नहीं बन जाता। हो सकता है वह L1 और L4 दोनों में दिखे, लेकिन दोनों घटनाएँ समय की दृष्टि से स्वतंत्र और असंबंधित व्यवहार हों।
इसलिए हम एक ऐसा फ़ंक्शन परिभाषित करते हैं जो “क्रॉस-लेयर समन्वय” का संख्यात्मक मूल्यांकन करता है। इसे coherence फ़ंक्शन C(i,t) कहा जाता है।
यह फ़ंक्शन अवधारणात्मक रूप से चार तत्वों को जोड़ता है।
- क्रॉस-लेयर कपलिंग की मज़बूती — कौन-कौन सी लेयर्स एक साथ देखी गईं
- समय की निकटता — ऑब्ज़र्वेशन की टाइमिंग कितनी करीब है
- ऑब्ज़र्वेशन का परिमाण — प्रत्येक लेयर में ऑब्ज़र्वेशन की मात्रा (count)
- समय के साथ क्षय (decay) — पुराने ऑब्ज़र्वेशन का प्रभाव घटता जाता है
विशिष्ट गणितीय रूप (क्रॉस-लेयर कपलिंग मैट्रिक्स K_ℓk, decay दर γ, इंटेंसिटी टर्म Φ आदि) हमारी पेटेंट फाइलिंग (2026) के कारण गैर-सार्वजनिक है, लेकिन अवधारणात्मक रूप से यह इस रूप में होता है:
C(i,t) = function of "cross-layer coupling × temporal proximity × observation magnitude × temporal decay"C(i,t) की वैल्यू 0 और 1 के बीच होती है। वैल्यू जितनी बड़ी हो, उतनी ही अधिक संभावना है कि उस IP का व्यवहार “लेयर्स के आर-पार समन्वित” है।
5. कैंपेन निर्धारण — थ्रेशोल्ड पार होने पर स्वचालित कार्रवाई #
प्रत्येक IP के लिए C(i,t) की गणना करने के बाद, थ्रेशोल्ड पार करने वालों को “अटैक कैंपेन प्रगति में है” के रूप में आँका जाता है।
यहाँ के महत्वपूर्ण डिज़ाइन निर्णय:
- निर्णय निर्धारक (deterministic) है: coherence वैल्यू थ्रेशोल्ड से ऊपर है या नहीं — यह यांत्रिक रूप से जाँचा जाता है। हम LLM के अनुमान पर निर्भर नहीं रहते
- थ्रेशोल्ड प्रति-एनवायरनमेंट समायोज्य हैं: डिफ़ॉल्ट वैल्यू आंतरिक proof-of-concept से तय की गई हैं, लेकिन ग्राहक के एनवायरनमेंट के अनुसार फ़ाइन-ट्यून की जा सकती हैं
- निर्णय का तर्क व्याख्येय (explainable) है: सारा आउटपुट दिखाता है कि “किन लेयर्स में कितनी बार ऑब्ज़र्वेशन हुए, इसलिए कैंपेन निर्धारित किया गया”
निर्णय-तर्क के आउटपुट का उदाहरण (वैल्यू मास्क की गई हैं):
[COHERENCE_CAMPAIGN] ip=203.0.113.42 C=███
L1_network: count=███ first=████ last=████
L4_app: count=███ first=████ last=████
reason: layer_count=2 + coherence > thresholdचूँकि निर्धारण का आधार स्पष्ट रूप से दिखाया जाता है, ऑपरेटर स्वयं देखे गए तथ्यों की पुष्टि कर सकते हैं और AI के ब्लैक-बॉक्स निर्णय पर भरोसा करने के बजाय, समझ के आधार पर स्वचालित डिफेंस को अनुमोदित कर सकते हैं।
6. समन्वित अटैक ग्रुप डिटेक्शन — “समूह के रूप में समन्वय” का पता लगाना #
अब तक हमने यह देखा कि “एक अकेला IP कई लेयर्स में समन्वित है या नहीं”। यह अकेला भी शक्तिशाली है, लेकिन असली दुनिया के अटैक इससे भी ज़्यादा परिष्कृत होते हैं।
उदाहरण के लिए, क्लाउड प्रोवाइडर्स पर कई IP का उपयोग करके किया जाने वाला संगठित vulnerability स्कैनिंग। हर IP की व्यक्तिगत फ़्रीक्वेंसी इतनी कम होती है कि वह कैंपेन डिटेक्शन थ्रेशोल्ड पार नहीं करती, लेकिन पूरे subnet या ASN में एकत्रित करने पर गतिविधि स्पष्ट रूप से संगठित नज़र आती है।
इसलिए BASTION में एक तंत्र है जो “IP का मूल्यांकन ग्रुप-इकाइयों में” करता है।
- Subnet के आधार पर ग्रुपिंग — एक ही /24 के IP समूह को एक सेट माना जाता है
- ASN के आधार पर ग्रुपिंग — एक ही ASN के IP समूह को एक सेट माना जाता है
हर ग्रुप के लिए हम group coherence (GC) की गणना करते हैं। GC प्रत्येक सदस्य IP की coherence वैल्यू का एकत्रीकरण है, जिसे ग्रुप के आकार के आधार पर एक बूस्ट गुणांक से गुणा किया जाता है।
इसका विशिष्ट गणितीय रूप भी गैर-सार्वजनिक है, लेकिन अवधारणा सरल है:
GC = Σ C(i,t) × boost(group_size)10 IP से बने ग्रुप में “संगठित अटैक” की संभावना 3 IP वाले ग्रुप की तुलना में अधिक होती है, इसलिए बूस्ट प्रभावी हो जाता है।
इस तंत्र को group correlation डिटेक्शन (समन्वित अटैक ग्रुप डिटेक्शन) कहा जाता है। यह इस विचार को गणितीय रूप से मॉडल करता है कि “जो सिग्नल अकेले-अकेले छोटे हैं, वे समूह के रूप में देखने पर सामूहिक रूप से गहरा महत्व रख सकते हैं”।
7. वास्तविक ऑपरेशंस का डिटेक्शन उदाहरण (गुमनाम किया हुआ) #
यहाँ हमारे आंतरिक प्रोडक्शन एनवायरनमेंट (मई 2026 तक की स्थिति) में group correlation डिटेक्शन द्वारा पकड़े गए एक ग्रुप का उदाहरण है, जिसमें IP और संगठन के नाम मास्क किए गए हैं।
[GROUP_CAMPAIGN] type=asn group=AS█████ size=17 GC=███
Member IPs: ████.██.██.███, ████.███.██.██, ███.███.███.███, ... (17 items)
Observed layers: L1_network (FW block), L4_app (vuln scan)
Time window: 24 hours
Action: All 17 IPs auto-blocked across boundary FW + DMZ Agentsयह एक ऐसा केस है जिसमें एक प्रमुख क्लाउड प्रोवाइडर के 17 IP से 24 घंटों के भीतर 2 लेयर्स (FW स्कैनिंग और वेब vulnerability स्कैनिंग) में संगठित गतिविधि देखी गई। हर व्यक्तिगत IP की मात्रा पारंपरिक SIEM में कैंपेन डिटेक्शन ट्रिगर करने के लिए अपर्याप्त थी, लेकिन ग्रुप के रूप में यह गतिविधि स्पष्ट रूप से जान-बूझकर की गई गतिविधि का संकेत दे रही थी।
डिटेक्शन के बाद, सभी 17 IP को एक साथ बाउंड्री FW और पब्लिक सर्वर-साइड DMZ Agent समूहों में प्रोपेगेट कर ब्लॉक कर दिया गया (cascade defense; इसका विवरण एक अलग आगामी लेख में)।
8. यह SIEM/SOAR से अलग क्यों है #
पारंपरिक SIEM या SOAR में भी correlation रूल्स लिखकर “कई डिवाइसों के डिटेक्शन निर्णयों को जोड़ना” वास्तव में हासिल किया जा सकता है। तो फिर अलग क्या है?
| पहलू | पारंपरिक SIEM | BASTION Multi-Layer Correlation |
|---|---|---|
| रूल परिभाषा | हर रूल हाथ से लिखा जाता है | गणितीय निर्णय द्वारा स्वचालित |
| लेयर की अवधारणा | डिवाइस इकाई | अटैक-प्रगति चरण इकाई |
| ग्रुपिंग | हर रूल के लिए अलग-अलग | गणितीय मॉडल द्वारा एकसमान |
| निर्णय की व्याख्येयता | केवल रूल का नाम | ऑब्ज़र्वेशन मात्रा + तर्क का आउटपुट |
| डिज़ाइनर की पूर्वधारणा | ज्ञात परिदृश्य | अज्ञात संयोजनों का भी पता लगाता है |
सबसे बड़ा अंतर यह है कि “यह अज्ञात परिदृश्यों का पता लगा सकता है”। SIEM उन अटैकों को चूक जाता है जो उसके रूल्स में नहीं लिखे गए। Multi-layer correlation क्रॉस-लेयर समन्वय की एक सार्वभौमिक विशेषता की जाँच करता है, इसलिए यह नए अटैक तरीकों के अनुसार भी ढल जाता है।
9. डिज़ाइन ट्रेडऑफ़ #
स्पष्ट रूप से कहें तो, इस तंत्र में कई ट्रेडऑफ़ हैं।
1. कम्प्यूटेशनल लागत: सभी IP के लिए C(i,t) की गणना करने पर, देखे गए IP की संख्या बढ़ने के साथ प्रोसेसिंग समय बढ़ता है। BASTION इसे कम करने के लिए गणना को trace-registry में रिकॉर्ड किए गए हालिया सक्रिय IP तक सीमित रखता है।
2. थ्रेशोल्ड समायोजन: थ्रेशोल्ड कम करने पर false positives बढ़ते हैं; बढ़ाने पर चूकें बढ़ती हैं। यह एनवायरनमेंट पर निर्भर है, और सुरक्षित तरीका यह है कि शुरुआत में इसे सतर्कता से ऊँचा रखा जाए और ऑब्ज़र्वेशन के साथ धीरे-धीरे कम किया जाए।
3. ज्ञात IP के लिए false negatives: whitelist में शामिल IP (अपने सर्वर, बिज़नेस पार्टनर, CDN आदि) को निर्णय से बाहर रखना ज़रूरी है। इसे एक अलग तंत्र के माध्यम से मैनेज किया जाता है।
4. बड़े क्लाउड ASN की विशेषताएँ: AWS या Microsoft जैसे बड़े पैमाने के ASN में कई वैध यूज़र शामिल होते हैं। भले ही group correlation डिटेक्शन बड़े ग्रुप साइज़ दिखाए, उन्हें तुरंत ब्लॉक नहीं करना चाहिए; CAP (प्रति ग्रुप अधिकतम ब्लॉक किए गए IP) द्वारा उन्हें सुरक्षित रूप से सीमित रखा जाता है।
इन सबको डिज़ाइन चरण में ही पहचान लिया गया था और उपयुक्त उपाय मौजूद हैं। BASTION के डिज़ाइन सिद्धांतों में से एक है “safety envelope” — यानी हमेशा ऐसे तंत्र शामिल करना जो किसी चीज़ के नियंत्रण से बाहर जाने पर नुकसान को भौतिक रूप से सीमित कर दें।
10. भविष्य का विकास #
Multi-layer correlation इंजन स्वयं पर्याप्त परिचालन परिपक्वता तक पहुँच चुका है, लेकिन सुधार की गुंजाइश अभी बाकी है।
- अनुकूली (adaptive) थ्रेशोल्ड: एनवायरनमेंट के सामान्य स्तर सीखकर थ्रेशोल्ड को स्वतः समायोजित करना (अवधारणा चरण में)
- समय-आधारित संवेदनशीलता समायोजन: रात के समय और बिज़नेस घंटों में अलग-अलग संवेदनशीलता लागू करना
- अन्य परिचालन क्षेत्रों में विस्तार: सिक्योरिटी से आगे के परिचालन क्षेत्रों (क्वालिटी, परफ़ॉर्मेंस) में अनुप्रयोग (मूल्यांकन के अधीन)
- ASN ट्रस्ट स्कोर: पिछले व्यवहार के आधार पर हर क्लाउड ASN के लिए विश्वास स्तर की गणना
इन्हें क्रमिक रूप से लागू किया जाएगा।
11. संबंधित लेख #
- BASTION को “सिक्योरिटी प्रोडक्ट” से “AI Ops प्लेटफ़ॉर्म” में विकसित करना — multi-layer correlation सहित BASTION के समग्र विकास की कहानी
- Coming soon DMZ के लिए हल्का Agent और वेरिफ़िकेशन इंजन
- Coming soon लोकल LLM का उपयोग करते हुए इंफ्रास्ट्रक्चर लॉग का स्वचालित एनालिसिस
- LLM Hallucination Audit का कार्यान्वयन — AI द्वारा लिखे गए आँकड़ों की वास्तविक-डिवाइस लॉग से क्रॉस-चेकिंग
12. हमसे संपर्क करें #
BASTION अपनाने पर विचार कर रही कंपनियाँ और joint proof-of-concept प्रोग्राम में रुचि रखने वाले संगठन, कृपया संपर्क फ़ॉर्म के माध्यम से हमसे संपर्क करें।
केवल सिक्योरिटी मॉड्यूल की तैनाती या क्वालिटी मॉड्यूल सहित फ़ुल-स्टैक तैनाती — दोनों उपलब्ध हैं। हम आपके स्कोप के आधार पर व्यक्तिगत प्रस्ताव प्रदान करेंगे।