हम बॉक्स से बाहर काम कर रहे सहसंबंध के नियमों के लिए समर्पित लेखों की श्रृंखला को समाप्त करते हैं। हमने एक दृष्टिकोण निर्धारित करने के लिए एक लक्ष्य निर्धारित किया है जो हमें सहसंबंध नियमों को बनाने की अनुमति देगा जो कि कम से कम झूठी सकारात्मक के साथ "बॉक्स से बाहर" काम कर सकते हैं।


चित्र: सॉफ्टवेयर मार्केटिंग

लेख के सभी प्रमुख बिंदु निष्कर्ष में उपलब्ध हैं, उसी स्थान पर इस पद्धति को ग्राफिक आरेख के रूप में प्रस्तुत किया गया है ।

पिछले लेखों में क्या था, इसके बारे में संक्षेप में: उन्होंने बताया कि सामान्यीकृत घटना के क्षेत्रों का एक सेट कैसा दिखना चाहिए - एक योजना ; कौन सी घटना वर्गीकरण प्रणाली का उपयोग करने के लिए; घटनाओं को सामान्य बनाने की प्रक्रिया को एकीकृत करने के लिए एक वर्गीकरण प्रणाली और एक योजना का उपयोग कैसे करें। हमने सहसंबंध नियमों के कार्यान्वयन के संदर्भ में भी जांच की और जांच की कि क्या स्वैच्छिक प्रणाली (एएस) के बारे में क्या पता होना चाहिए कि यह निगरानी कर रहा है और क्यों।

उपरोक्त सभी दृष्टिकोण और तर्क ब्लॉक हैं जहां से सहसंबंध नियम विकसित करने की पद्धति का निर्माण किया जाता है। यह उन्हें एक साथ रखने और पूरी तस्वीर को देखने का समय है।

सहसंबंध नियम विकसित करने की पूरी पद्धति में चार खंड होते हैं:

• स्रोतों और परिवेश की तैयारी;
• घटनाओं और उनके संवर्धन का सामान्यीकरण;
• एएस के संदर्भ में सहसंबंध के नियमों का अनुकूलन;
• सकारात्मक पर एक समझौते का गठन।

स्रोत और वातावरण तैयार करना

सहसंबंध नियम उन घटनाओं पर काम करते हैं जो स्रोत उत्पन्न करते हैं। इस संबंध में, यह अत्यंत महत्वपूर्ण है कि सहसंबंध नियमों के लिए आवश्यक स्रोत वक्ताओं में मौजूद हैं और सही ढंग से कॉन्फ़िगर किए गए हैं।


स्रोत और वातावरण तैयार करना

चरण 1 : नियम के सामान्य तर्क पर विचार करें और समझें कि घटना स्रोतों की क्या आवश्यकता है। यदि आप खरोंच से विकसित हो रहे हैं या तैयार सिग्मा -सहसंबंध नियम ले रहे हैं , तो आपको उन घटनाओं के आधार पर समझने की आवश्यकता है कि वे किन स्रोतों से काम करेंगे।

चरण 2 : सुनिश्चित करें कि सभी आवश्यक स्रोत कंपनी में हैं और उन्हें एकत्र किया जा सकता है। एक स्थिति संभव है जब कोई नियम प्रपत्र के कई स्रोतों (घटना ए से स्रोत 1 से घटना) की एक श्रृंखला पर संचालित होता है - (स्रोत 2 से घटना बी) - (स्रोत 3 से घटना सी) 5 मिनट के लिए। यदि आपकी कंपनी में कम से कम एक स्रोत नहीं है, तो ऐसा नियम बेकार हो जाता है, क्योंकि यह कभी भी काम नहीं करेगा। आपको यह समझने की आवश्यकता है कि क्या, सिद्धांत रूप में, आवश्यक स्रोतों से घटनाओं को इकट्ठा करना संभव है और क्या आपका सीएमजी इसे प्रदान कर सकता है। उदाहरण के लिए, स्रोत किसी फ़ाइल में ईवेंट लिखता है, लेकिन फ़ाइल को एन्क्रिप्ट किया जाता है, या भंडारण के लिए स्रोत पर एक गैर-मानक डेटाबेस का उपयोग किया जाता है, जिसके लिए मानक ODBC / JDBC ड्राइवर के माध्यम से पहुंच सुनिश्चित नहीं की जा सकती है।

चरण 3 : स्रोतों को कनेक्ट करने के लिए सिएम। भले ही यह कितना भी अच्छा क्यों न लगे, लेकिन इस कदम पर घटनाओं के संग्रह को लागू करना आवश्यक है। अक्सर कई समस्याएं होती हैं। उदाहरण के लिए, संगठनात्मक समस्याएं, जब आईटी प्रबंधन स्पष्ट रूप से मिशन महत्वपूर्ण प्रणालियों से जुड़ने पर रोक लगाता है। या तकनीकी, जब अतिरिक्त सेटिंग्स के बिना, इवेंट्स इकट्ठा करते समय, CRM एजेंट (SmartConnector, यूनिवर्सल फ़ॉरवर्डर), बस स्रोत को "मारता है", सेवा से वंचित कर देता है। इसे अत्यधिक लोड किए गए DBMS को CRM से कनेक्ट करते समय अक्सर देखा जा सकता है।

चरण 4 : सुनिश्चित करें कि स्रोतों पर ऑडिट सही ढंग से कॉन्फ़िगर किया गया है, सहसंबंध के लिए आवश्यक घटनाओं को कोलम्बिया में प्राप्त किया गया है। सहसंबंध नियम कुछ प्रकार की घटनाओं की अपेक्षा करते हैं। उन्हें स्रोत द्वारा उत्पन्न किया जाना चाहिए। अक्सर ऐसा होता है कि नियमों के लिए आवश्यक घटनाओं को उत्पन्न करने के लिए, स्रोत को अतिरिक्त रूप से कॉन्फ़िगर किया जाना चाहिए: उन्नत ऑडिट सक्षम है और एक निश्चित प्रारूप में लॉग आउटपुट कॉन्फ़िगर किया गया है।

विस्तारित ऑडिटिंग को सक्रिय करने से अक्सर स्रोत से स्रोत में ईपीएस प्रवाह (ईपीएस) की मात्रा प्रभावित होती है। इस तथ्य के कारण कि स्रोत स्वयं और डब्लूडीएम विभिन्न विभागों की जिम्मेदारी के क्षेत्र में हैं, हमेशा एक जोखिम होता है कि विस्तारित ऑडिट को अक्षम किया जा सकता है और, परिणामस्वरूप, आवश्यक प्रकार की ईवेंट्स, डब्लूएमआर में आना बंद हो जाएंगे। इस समस्या को प्रत्येक स्रोत के लिए घटनाओं के प्रवाह की निगरानी करके, या बल्कि, प्रति सेकंड (ईपीएस) ईवेंट में परिवर्तनों की निगरानी करके आंशिक रूप से पता लगाया जा सकता है।

चरण 5 : सत्यापित करें कि घटनाएं प्रगति पर हैं और स्रोत निगरानी को कॉन्फ़िगर करें। किसी भी बुनियादी ढांचे में, जितनी जल्दी या बाद में, नेटवर्क या स्रोत में विफलताएं स्वयं प्रकट होती हैं। इस बिंदु पर, CRM स्रोत से संपर्क खो देता है और ईवेंट प्राप्त नहीं कर सकता है। यदि स्रोत निष्क्रिय है और किसी फ़ाइल या डेटाबेस में इसके लॉग लिखता है, तो विफलता की स्थिति में ईवेंट्स नहीं खोएंगे, और संचार बहाल होने पर सिएम उन्हें प्राप्त कर सकेंगे। यदि स्रोत सक्रिय है और उदाहरण के लिए, syslog के माध्यम से, कहीं भी अतिरिक्त रूप से उन्हें सहेजे बिना, तो ईवेंट्स खो जाएगा, तो ईवेंट खो जाएगा, और आपका सहसंबंध नियम केवल काम नहीं करेगा, क्योंकि वांछित ईवेंट प्रतीक्षा नहीं करेगा। गहरी खुदाई करते हुए, आप देख सकते हैं कि, एक निष्क्रिय स्रोत के साथ काम करते समय, जब विफलता के बाद संचार बहाल करते हैं, तो कोई गारंटी नहीं है कि सहसंबंध नियम बाहर काम करेंगे, विशेष रूप से वे जो समय खिड़कियों के साथ काम करते हैं। ऊपर वर्णित नियम उदाहरण पर विचार करें: (स्रोत 1 से घटना ए) - (स्रोत 2 से घटना बी) - (स्रोत 3 से घटना सी) 5 मिनट के लिए। यदि ईवेंट B के बाद कोई विफलता होती है और कनेक्शन एक घंटे में पुनर्स्थापित हो जाता है, तो सहसंबंध काम नहीं करेगा, क्योंकि इवेंट C अपेक्षित 5 मिनट में नहीं आएगा।

इन विशेषताओं को ध्यान में रखते हुए, आपको उन स्रोतों की निगरानी को कॉन्फ़िगर करना चाहिए जिनसे इवेंट एकत्र किए जाते हैं। यह निगरानी स्रोतों की उपलब्धता, उनसे घटनाओं के आगमन की समयबद्धता, एकत्रित घटनाओं (ईपीएस) के प्रवाह की शक्ति की निगरानी करना चाहिए।

मॉनिटरिंग सिस्टम की ट्रिगरिंग पहली घंटी है जो सहसंबंध नियमों के सभी या कुछ हिस्सों के प्रदर्शन को प्रभावित करने वाले एक नकारात्मक कारक की उपस्थिति की बात करती है।

घटनाओं का सामान्यीकरण और उनका संवर्धन

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


घटनाओं का सामान्यीकरण और संवर्धन

चरण 6 और चरण 7 : कार्यप्रणाली के आधार पर, श्रेणी के अनुसार घटनाओं का वर्गीकरण और सामान्यीकरण। हम उन पर विस्तार से ध्यान नहीं देंगे, क्योंकि हमने इन चरणों को "घटनाओं को सामान्य बनाने के लिए पद्धति" लेख में विस्तार से माना था।

चरण 8 : श्रेणी के अनुसार, लापता और अतिरिक्त जानकारी के साथ घटनाओं का संवर्धन। अक्सर, आने वाली घटनाओं में हमेशा सहसंबंध नियमों के काम करने के लिए आवश्यक हद तक जानकारी नहीं होती है। उदाहरण के लिए, किसी ईवेंट में केवल होस्ट का IP पता होता है, लेकिन इसके FQDN या Hostname के बारे में कोई जानकारी नहीं होती है। एक अन्य उदाहरण: एक ईवेंट में एक उपयोगकर्ता ID होती है, लेकिन ईवेंट में कोई उपयोगकर्ता नाम नहीं होता है। इस मामले में, आवश्यक जानकारी को बाहरी स्रोतों - डेटाबेस, डोमेन नियंत्रक या अन्य निर्देशिकाओं से निकाला जाना चाहिए और घटना में जोड़ा जाना चाहिए।

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

एएस संदर्भ के लिए सहसंबंध नियमों का पालन

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


एएस संदर्भ के लिए सहसंबंध नियमों का पालन

चरण 9 : प्रत्येक स्रोत से घटनाओं की आवृत्ति को समझें, सहसंबंध के लिए समय खिड़की निर्धारित करें। अक्सर, सहसंबंध नियम समय खिड़कियों का उपयोग करते हैं जब किसी निश्चित समय अंतराल के भीतर एक निश्चित घटना के आगमन की अपेक्षा करना आवश्यक होता है। ऐसे नियमों को विकसित करते समय, घटनाओं को प्राप्त करने में देरी पर विचार करना महत्वपूर्ण है। वे आमतौर पर दो कारकों के कारण होते हैं।

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

दूसरी बात यह है कि इवेंट्स की डिलीवरी से लेकर सीएमजी तक पहुंचने में देरी हुई है। उदाहरण के लिए, डेटाबेस से घटनाओं का संग्रह कॉन्फ़िगर किया गया है ताकि हर 10 मिनट में एक बार घटनाओं का अनुरोध किया जाए, ज़ाहिर है, 5 मिनट की सहसंबंध खिड़की इस स्थिति में सबसे अच्छा समाधान नहीं है।

समस्या जटिल हो जाती है जब एक सहसंबंध नियम विकसित करना आवश्यक होता है जो एक साथ कई स्रोतों से घटनाओं के साथ काम करता है। इस मामले में, यह समझना महत्वपूर्ण है कि उनकी डिलीवरी का समय अलग हो सकता है। सबसे खराब स्थिति में, कालक्रम के उल्लंघन के साथ घटनाएं यादृच्छिक क्रम में आएंगी। ऐसी स्थिति में, सहसंबंध नियमों के विकासकर्ता को यह स्पष्ट रूप से समझने की आवश्यकता है कि किस समय कोलम्बिया को सहसंबंध का पता चलता है (घटना के समय में या जब घटना का आगमन हुआ था)। मैं ध्यान देता हूं कि घटनाओं के आगमन के समय में सहसंबंध छद्म वास्तविक समय मोड में घटनाओं के प्रसंस्करण के लिए सबसे तकनीकी रूप से सरल और सामान्य विकल्प है। हालांकि, यह विकल्प केवल उपरोक्त समस्याओं को बढ़ाता है, और उन्हें हल नहीं करता है।

यदि आपका CRM ईवेंट समय में सहसंबंध प्रदान करता है, तो सबसे अधिक संभावना है कि ईवेंट को पुन: व्यवस्थित करने के लिए तंत्र हैं जो घटनाओं के वास्तविक कालक्रम को पुनर्स्थापित कर सकते हैं।

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

चरण 10 : एक अपवाद तंत्र स्थापित करें। वास्तविक दुनिया में, विशेष व्यवहार के साथ हमेशा एक वस्तु होगी जिसे एक विशिष्ट सहसंबंध नियम द्वारा नियंत्रित नहीं किया जाना चाहिए, क्योंकि यह एक झूठी सकारात्मक की ओर जाता है। इसलिए, नियमों के विकास के चरण में, ऐसी वस्तुओं को अपवादों में जोड़ने के लिए तंत्र को रखा जाना चाहिए। उदाहरण के लिए, यदि आपका नियम मशीनों के आईपी पते के साथ काम करता है, तो आपको एक तालिका सूची की आवश्यकता है जहां आप उन पते जोड़ सकते हैं जिनके लिए नियम काम नहीं करेगा। इसी तरह, यदि कोई नियम उपयोगकर्ता लॉगिन या प्रक्रिया नामों के साथ काम करता है, तो नियम तर्क में तालिका अपवर्जन सूची के साथ पूर्वगामी रूप से काम करना आवश्यक है।

यह दृष्टिकोण आपको नियम के निकाय को फिर से लिखे बिना अपवादों को स्वचालित रूप से या मैन्युअल रूप से जोड़ने की अनुमति देगा।

चरण 11 : सहसंबंध नियम की प्रयोज्यता की भौतिक और तार्किक सीमाओं को परिभाषित करें। एक सहसंबंध नियम विकसित करते समय, शुरू में नियम की प्रयोज्यता (गुंजाइश) की सीमाओं को समझना महत्वपूर्ण है, और क्या वे सभी मौजूद हैं। जब तर्क का काम करते हैं और नियम को डिबग करते हैं, तो इस क्षेत्र की बारीकियों पर ध्यान देना आवश्यक है। यदि कोई नियम इस क्षेत्र के दायरे से परे जाने वाले डेटा के साथ काम करना शुरू कर देता है, तो झूठी सकारात्मकता की संभावना बढ़ जाती है।

दो प्रकार के दायरे को प्रतिष्ठित किया जा सकता है: भौतिक और तार्किक। भौतिक क्षेत्र कंपनी और आसन्न नेटवर्क है, और तार्किक क्षेत्र एएस, व्यापार अनुप्रयोगों, या व्यावसायिक प्रक्रियाओं के हिस्से हैं। भौतिक क्षेत्र के उदाहरण: DMZ खंड, आंतरिक और बाहरी सबनेट, रिमोट एक्सेस नेटवर्क। नियमों के तार्किक दायरे के उदाहरण: प्रक्रिया नियंत्रण, लेखांकन, पीसीआई डीएसएस खंड, पीडी खंड, या सिर्फ विशिष्ट उपकरण भूमिकाएं - डोमेन नियंत्रक, एक्सेस स्विच, कोर राउटर।

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

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

चरण 12 : संदर्भ को स्पष्ट करने के लिए स्पीकर मॉडल का उपयोग करें। एक सहसंबंध नियम विकसित करने की प्रक्रिया में जो दुर्भावनापूर्ण कार्यों की पहचान करता है, यह सुनिश्चित करना महत्वपूर्ण है कि उन्हें वास्तव में लागू किया जा सकता है। यदि इस पर ध्यान नहीं दिया जाता है, तो संभावित हमले का पता लगाने वाले नियम का ट्रिगर गलत हो जाएगा, क्योंकि इस प्रकार का हमला केवल आपके बुनियादी ढांचे पर लागू नहीं हो सकता है। मैं एक उदाहरण के साथ समझाऊंगा:

1. मान लीजिए कि हमारे पास एक सहसंबंध नियम है जो दूरस्थ आरडीपी कनेक्शन का सर्वर से पता लगाता है।
2. फ़ायरवॉल myserver.local सर्वर TCP पोर्ट 3389 से कनेक्ट करने का प्रयास लाता है।
3. नियम आग लगाता है, और आप उच्च प्राथमिकता के साथ एक संभावित घटना को पार्स करना शुरू करते हैं।

जांच के दौरान, आपको जल्दी से पता चलता है कि myserver.local 3389 पर यह बंद है और किसी भी सेवा द्वारा कभी नहीं खोला गया है और लिनक्स है। यह एक गलत सकारात्मक है, जिसकी जांच में आपको समय लगा।

एक और उदाहरण: IPS एक सिग्नेचर ट्रिगरिंग इवेंट भेजता है जब भेद्यता CVE-2017-0144 के दोहन का प्रयास किया जाता है, लेकिन जांच के दौरान यह पता चलता है कि संबंधित पैच अटैक मशीन पर स्थापित है और उच्चतम प्राथमिकता के साथ ऐसी घटना का जवाब देने की कोई आवश्यकता नहीं है।
स्पीकर मॉडल से डेटा का उपयोग करने से इस समस्या को समतल करने में मदद मिलेगी।

चरण 13 : इकाई पहचानकर्ताओं का उपयोग करें, न कि उनके स्रोत कीज़ का। जैसा कि पहले से ही लेख "सिस्टम मॉडल के रूप में सहसंबंध नियमों के संदर्भ में", आईपी ​​पते, FQDN, और यहां तक ​​कि एक परिसंपत्ति के मैक को बदल सकते हैं। इस प्रकार, यदि आप सहसंबंध नियम या तालिका सूची में संपत्ति के स्रोत पहचानकर्ताओं का उपयोग करते हैं, तो थोड़ी देर के बाद पूरी तरह से प्रतिबंधात्मक कारण के लिए झूठी सकारात्मक प्राप्त करने का एक उच्च मौका है, उदाहरण के लिए, डीएचसीपी सर्वर ने बस इस आईपी को किसी अन्य मशीन को जारी किया है।

यदि आपके CRM में परिसंपत्तियों की पहचान करने, उनके परिवर्तनों को ट्रैक करने और आपको उनके पहचानकर्ताओं के साथ काम करने की अनुमति देने के लिए एक तंत्र है, तो आपको पहचानकर्ताओं का उपयोग करना चाहिए, न कि परिसंपत्ति की स्रोत कुंजियों का।

एक सकारात्मक समझौते का गठन

सहसंबंध नियम बनाने के अंतिम ब्लॉक का अनुमोदन करते हुए, हम याद करते हैं कि नियम का परिणाम एक घटना है जो कि कोलम्बिया में सामने आई है। जिम्मेदार पेशेवरों को इस तरह की घटना का जवाब देना चाहिए। यद्यपि लेखों की इस श्रृंखला के उद्देश्य में घटना प्रतिक्रिया प्रक्रिया पर विचार शामिल नहीं है, यह ध्यान दिया जाना चाहिए कि घटना पर जानकारी का हिस्सा संबंधित सहसंबंध नियम बनाने के चरण में पहले से ही उत्पन्न होता है।

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


एक सकारात्मक समझौते का गठन

चरण 14 : झूठी सकारात्मकता की एक बड़ी संख्या के मामले में एकत्रीकरण और शटडाउन की शर्तों को निर्धारित करें। डिबगिंग चरण में, और इसके कामकाज की प्रक्रिया में, यदि आप इस तकनीक का पालन नहीं करते हैं :), नियमों के झूठे अलार्म हो सकते हैं। यह अच्छा है अगर प्रति दिन एक या दो यात्राएं हों, लेकिन क्या होगा अगर एक नियम में हजारों या दसियों हजार यात्राएं हों? बेशक, यह बताता है कि नियम को और विकसित करने की आवश्यकता है। हालांकि, यह सुनिश्चित करना आवश्यक है कि ऐसी स्थितियों में ऐसे बड़े पैमाने पर गलत सकारात्मक:

1. इसने CRM प्रदर्शन को प्रभावित नहीं किया।
2. झूठी सकारात्मकता के द्रव्यमान के बीच, वास्तव में महत्वपूर्ण घटनाएं नहीं खोई थीं। कई झूठी गतिविधियों के पीछे मुख्य दुर्भावनापूर्ण गतिविधि को छिपाने के उद्देश्य से एक अलग प्रकार का हमला भी है।

इस तरह की समस्याओं को हल किया जा सकता है, यदि, संपूर्ण प्रणाली के स्तर पर एक संपूर्ण नियम के रूप में या प्रत्येक नियम के लिए अलग से सहसंबंध नियम बनाते समय, घटनाओं के एकत्रीकरण के लिए नियम और आपातकालीन बंद के लिए शर्तें निर्धारित की जा सकती हैं।

घटना एकत्रीकरण तंत्र लाखों समान घटनाओं को बनाने की अनुमति नहीं देगा, लेकिन एक को नई घटनाओं को "गोंद" करने के लिए, बशर्ते कि वे समान हों। चरम मामलों में, जब घटनाओं का एकत्रीकरण भी एक महत्वपूर्ण भार देता है, तो सहसंबंध नियम को स्वचालित रूप से बंद करने की सिफारिश की जाती है जब प्रति यूनिट समय की निर्दिष्ट संख्या (मिनट, घंटे, दिन) से अधिक हो जाती है।

चरण 15 : घटना का नाम उत्पन्न करने के लिए नियमों को परिभाषित करें। इस आइटम को अक्सर उपेक्षित किया जाता है, खासकर यदि वे अपनी कंपनी के लिए नियम विकसित नहीं कर रहे हैं, उदाहरण के लिए, यदि कोई तृतीय-पक्ष कंपनी, कोलम्बिया को लागू करने और नियमों को विकसित करने के लिए जिम्मेदार है। सहसंबंध नियम का नाम, साथ ही यह उत्पन्न होने वाली घटना, संक्षिप्त होना चाहिए और स्पष्ट रूप से एक विशेष नियम का सार दर्शाता है।

यदि आपकी कंपनी में एक से अधिक व्यक्ति घटनाओं और सहसंबंध नियमों के साथ काम करते हैं, तो यह अनुशंसा की जाती है कि आप नामकरण नियम विकसित करें। उन्हें डब्लूडीएम के साथ काम करने वाली पूरी टीम को समझना और स्वीकार करना होगा।

चरण 16 : घटना के महत्व को आकार देने के लिए नियमों को परिभाषित करें। किसी घटना को बनाने के अंतिम चरण में अधिकांश एमएमआर समाधान आपको इसका महत्व और महत्व निर्धारित करने की अनुमति देता है। कुछ निर्णय भी घटना के संदर्भ और उसमें शामिल वस्तुओं के आधार पर, स्वचालित रूप से महत्व की गणना करते हैं।

इस घटना में कि आपका सिएम घटनाओं के महत्व का विशेष रूप से स्वचालित गणना करता है, यह गणना किस और किस फॉर्मूले के आधार पर किया जाता है। उदाहरण के लिए, यदि महत्व की गणना घटना में शामिल परिसंपत्तियों के महत्व के आधार पर की जाती है, तो आपको पहले से एक कंपनी में एसेट मैनेजमेंट के मुद्दों को गंभीरता से लेने की आवश्यकता है।

यदि आप मैन्युअल रूप से किसी घटना के महत्व को निर्धारित करते हैं, तो यह अनुशंसा की जाती है कि आप एक गणना सूत्र विकसित करें जो कम से कम निम्नलिखित को ध्यान में रखे:

1. उस दायरे का महत्व जिसमें नियम काम करता है। उदाहरण के लिए, सिस्टम क्रिटिकल ज़ोन के सिस्टम में एक घटना अधिक क्रिटिकल हो सकती है, अगर बिजनेस क्रिटिकल सिस्टम के ज़ोन में एक ही घटना हुई हो।
2. घटना में शामिल संपत्ति और उपयोगकर्ता खातों का महत्व।
3. कंपनी में इस घटना की पुनरावृत्ति।

इसके अलावा, जैसा कि घटनाओं के नामकरण में, यह महत्वपूर्ण है कि सभी इच्छुक पक्ष स्पष्ट रूप से और समान रूप से उन नियमों को समझते हैं जिनके द्वारा किसी घटना का महत्व बनता है।

निष्कर्ष

लेखों की हमारी श्रृंखला के परिणामों को सारांशित करते हुए, मैं ध्यान देता हूं कि यह संभव है, मेरी राय में, सहसंबंध नियम बनाने के लिए जो बॉक्स से बाहर काम करते हैं। समाधान संगठनात्मक और तकनीकी दृष्टिकोण का एक संलयन हो सकता है। खुद ही कुछ करने में सक्षम होना चाहिए, लेकिन इसे संचालित करने वाले विशेषज्ञों को कुछ करना और जानना चाहिए।

संक्षेप में:

1. विधि में निम्नलिखित ब्लॉक शामिल हैं:
   
   • स्रोत और वातावरण तैयार करना।
   • घटनाओं का सामान्यीकरण और उनका संवर्धन।
   • एएस संदर्भ के लिए सहसंबंध नियमों का अनुकूलन।
   • सकारात्मक पर एक समझौते का गठन।
2. प्रत्येक इकाई में संगठनात्मक और तकनीकी घटक होते हैं।
3. एक तकनीकी दृष्टिकोण से, वर्णित ब्लॉक घटनाओं के संग्रह से एक घटना की पीढ़ी तक, लगभग सभी बुनियादी सिएम कार्यों को प्रभावित करते हैं।
4. इस पद्धति का लगभग पूरा तकनीकी घटक मौजूदा विदेशी द्वारा प्रदान किया जा सकता है, साथ ही साथ कुछ घरेलू सिएम समाधान भी।
5. इस पद्धति के चरणों का अधिक विस्तृत विचार और औचित्य चक्र के पिछले लेखों में दिया गया था। उनके लिंक लेख के अंत में दिए गए हैं ।

सहसंबंध नियम विकसित करने की पद्धति जो बॉक्स से बाहर काम करती है, उन

सभी के लिए बहुत धन्यवाद, जिन्होंने लेखों की पूरी श्रृंखला में महारत हासिल की, या कम से कम इन पंक्तियों के माध्यम से पढ़ा। यदि आपके कोई प्रश्न हैं - तो व्यक्तिगत रूप से लिखें या टिप्पणियों में पूछें। मुझे चर्चा करने में खुशी होगी।

---

लेखों की श्रृंखला:

सिएम गहराई: आउट-ऑफ-बॉक्स सहसंबंध। भाग 1: शुद्ध विपणन या एक बेकार समस्या?

सिएम गहराई: आउट-ऑफ-द-बॉक्स सहसंबंध। पार्ट 2. डेटा स्कीम में "दुनिया" के एक मॉडल के रूप में

सिएम की गहराई: संबंध "बॉक्स से बाहर" है। भाग 3.1।

सिएम गहराई घटनाओं का वर्गीकरण : आउट-ऑफ-बॉक्स सहसंबंध। भाग 3.2।

सेगमेन्ट डेप्थ इवेंट्स नॉर्मलाइज़ेशन मेथोडोलॉजी : आउट-ऑफ-बॉक्स कॉर्ड्रेसेज़। भाग 4. सिस्टम मॉडल, एमएमआर

डिपो सहसंबंध नियमों के संदर्भ के रूप में : आउट-ऑफ-द-बॉक्स सहसंबंध। भाग 5. सहसंबंध नियम विकसित करने की पद्धति ( यह लेख )