कैसे ठीक से घटना को सामान्य करने के लिए? कुछ भी भूल या भ्रमित किए बिना विभिन्न स्रोतों से समान घटनाओं को कैसे सामान्य किया जाए? लेकिन क्या होगा अगर दो विशेषज्ञ स्वतंत्र रूप से ऐसा करते हैं? इस लेख में, हम एक सामान्य सामान्यीकरण पद्धति साझा करेंगे जो इस समस्या को हल करने में मदद कर सकती है।


चित्र: Martinoflynn.com

ज्यादातर, सहसंबंध नियम सामान्यीकृत घटनाओं पर आधारित होते हैं। इस प्रकार, घटनाओं का सामान्यीकरण और यह कैसे सही ढंग से किया जाता है, सीधे सहसंबंध नियमों की सटीकता को प्रभावित करता है।

घटनाओं के सामान्यीकरण से उत्पन्न होने वाली समस्याओं को पहले लेख ( यहां ) में तैयार किया गया था, और समाधान बाद के लेख ( यहां और यहां ) में प्रस्तावित किए गए थे। अब हम पहले से वर्णित को संक्षेप में प्रस्तुत करते हैं और घटनाओं को सामान्य करने के लिए एक सामान्य दृष्टिकोण बनाते हैं।

शुरू करने के लिए, हम याद करते हैं कि हमने सामान्य स्तर के कौन से उपकरण विकसित किए हैं:

1. घटनाओं से पुनर्प्राप्त डेटा को संग्रहीत करने के लिए सामान्य फ़ील्ड स्कीमा आवश्यक है। इसकी विशेषताएं:
   
   
   • यह घटना में संस्थाओं की उपस्थिति को ध्यान में रखता है: विषय, वस्तु, स्रोत और घटनाओं के ट्रांसमीटर, साथ ही साथ संसाधन।
   • उन मामलों में सही सामान्यीकरण प्रदान करता है जब घटना में नेटवर्क स्तर और अनुप्रयोगों की इकाइयाँ होती हैं , और जब इसमें एक से अधिक विषय और / या ऑब्जेक्ट होते हैं।
   • आपको विषय और वस्तु के बीच बातचीत की प्रक्रिया की संरचना को स्पष्ट रूप से पहचानने और बनाए रखने की अनुमति देता है
2. घटना वर्गीकरण प्रणाली जो किसी आईटी या आईबी घटना के शब्दार्थ को प्रतिबिंबित करने में सक्षम है।

घटना सामान्यीकरण पद्धति

घटनाओं को सामान्य बनाने की पूरी कार्यप्रणाली में तीन चरण होते हैं:

1. घटना का विशेषज्ञ मूल्यांकन।
2. सहभागिता योजना की परिभाषा।
3. इवेंट श्रेणी परिभाषा।

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

मान लीजिए कि हमारे पास एक स्रोत है - DBMS ओरेकल डेटाबेस निम्नलिखित नेटवर्क पते के साथ:

• आईपी : 10.0.0.1;
• होस्टनाम : myoracle;
• FQDN : myoracle.local।

इस स्रोत से, CRM एजेंट निम्न घटना को उतारता है:

चरण 1. घटना का विशेषज्ञ मूल्यांकन

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

विशेषज्ञ कितनी सही तरह से घटना की व्याख्या करता है, इसके साथ समस्या वास्तविक है। उदाहरण के लिए, क्या कोई विशेषज्ञ समझ सकता है कि अगली घटना का क्या मतलब है?



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

आइए Oracle डेटाबेस से एक घटना के साथ मूल उदाहरण पर वापस जाएं। इस स्तर पर, विशेषज्ञ को इस तरह सोचना चाहिए:

" एक विशेषज्ञ के रूप में, मेरा मानना ​​है कि प्रारंभिक घटना एक Oracle डेटाबेस में एक उपयोगकर्ता द्वारा दूसरे से एक भूमिका को रद्द करने की प्रक्रिया का वर्णन करती है ।"

चरण 2. सहभागिता योजना का निर्धारण

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

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

1. नेटवर्क स्तर की इकाइयाँ
2. आवेदन स्तर की प्रविष्टियाँ।

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

आइए देखें कि कार्यप्रणाली का यह चरण प्रारंभिक उदाहरण पर कैसे काम करता है:

• नेटवर्क-स्तरीय सहभागिता योजना : एक ट्रांसमीटर के बिना एक पूर्ण प्रत्यक्ष संग्रह योजना।
• आवेदन स्तर पर बातचीत की योजना : एक संसाधन के माध्यम से बातचीत।

इन योजनाओं के लिए, निम्नलिखित सामान्यीकरण नियमों को परिभाषित किया जा सकता है:

1. नेटवर्क परत इकाइयाँ:
   
   • विषय :
     
     • फ़ील्ड: src.ip = <खाली>
     • फ़ील्ड: src.hostname = alex_host
     • फ़ील्ड: src.fqdn = <खाली>
   • वस्तु:
     
     • फ़ील्ड: dst.ip = 10.0.0.1
     • फ़ील्ड: dst.hostname = myoracle
     • फ़ील्ड: dst.fqdn = myoracle.local
   • स्रोत (मिलान वस्तु) :
     
     • फ़ील्ड: event_source.ip = 10.0.0.1
     • फ़ील्ड: event_source.hostname = myoracle
     • फ़ील्ड: event_source.fqdn = myoracle.local
   • ट्रांसमीटर :
     
     • फ़ील्ड: फ़ॉरवर्डर .ip = <खाली>
     • फ़ील्ड: फारवर्डर .होस्टनेम = <खाली>
     • फ़ील्ड: फ़ॉरवर्डर .fqdn = <खाली>
   • बातचीत का चैनल :
     
     • फ़ील्ड: इंटरैक्शन .id = 2342594
     
     
2. आवेदन स्तर की एंटिटीज (तत्वों का संग्रह):
   
   • विषय :
     
     • फ़ील्ड: विषय [1] .name = "एलेक्स"
     • फ़ील्ड: विषय [1] .type = "खाता"
   • वस्तु:
     
     • फ़ील्ड: ऑब्जेक्ट [1] .name = "बॉब"
     • फ़ील्ड: ऑब्जेक्ट [1] .type = "खाता"
   • संसाधन :
     
     • फ़ील्ड: संसाधन [1] .name = "MYROLE"
     • फ़ील्ड: संसाधन [1]। टाइप = "भूमिका"

चरण 3. एक घटना श्रेणी को परिभाषित करना

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

सामान्यीकरण को एकीकृत करने के लिए, वर्गीकरण प्रणाली निम्नलिखित नियमों को परिभाषित करती है:

1. आईटी और सूचना सुरक्षा घटनाओं के प्रत्येक स्तर की प्रत्येक श्रेणी के लिए, एक विशेषज्ञ सूचना की एक सूची के साथ एक निर्देशिका बनाता है जिसे प्रारंभिक घटना में पाया जाना चाहिए और सामान्यीकृत किया जाना चाहिए।
2. यदि किसी घटना को किसी भी श्रेणी को सौंपा गया था, तो विशेषज्ञ, निर्देशिका के अनुसार, आवश्यक जानकारी खोजने और उसे सामान्य करने के लिए बाध्य है।
3. प्रत्येक श्रेणी सामान्यीकृत घटना स्कीमा फ़ील्ड के एक सेट को परिभाषित करती है जिसे भरने की आवश्यकता होती है।

इस प्रकार, घटना के लिए चयनित श्रेणी के बीच एक सीधा पत्राचार स्थापित होता है:

• घटना शब्दार्थ;
• घटना से निकाले जाने वाली महत्वपूर्ण जानकारी, प्रत्यय श्रेणी के अनुसार;
• एक सामान्यीकृत घटना की योजना के क्षेत्रों का एक सेट जिसमें यह जानकारी "पुट" होनी चाहिए।

यह दृष्टिकोण आपको किसी भी घटना की श्रेणी से स्पष्ट रूप से समझने की अनुमति देता है कि सामान्यीकृत घटना के किन क्षेत्रों में डेटा है।

यदि, नए स्रोतों के समर्थन के साथ, यह पता चला है कि कुछ महत्वपूर्ण जानकारी को एक निश्चित श्रेणी की घटनाओं से अतिरिक्त रूप से निकाला जाना चाहिए, तो इसे निर्देशिका में दर्ज किया जाता है। इस मामले में, आपको आवश्यकता है:

• इवेंट स्कीमा के क्षेत्रों में भरने के लिए नियमों को परिभाषित करना;
• पहले से समर्थित सभी स्रोतों की इस श्रेणी में घटनाओं के लिए सामान्यीकरण की एक ऑडिट करें;
• पहले से सामान्यीकृत घटनाओं में नई जानकारी जोड़ें।

इस तरह, किए गए परिवर्तनों की संगति बनी रहती है। मूल उदाहरण पर विचार करें।

वर्गीकरण प्रणाली के अनुसार, इस घटना में निम्नलिखित श्रेणियां हैं:

• वर्गीकरण प्रणाली : आईटी इवेंट
• प्रथम स्तर श्रेणी (स्तर 1) : उपयोगकर्ता और अधिकार
• द्वितीय स्तर श्रेणी (स्तर 2) : उपयोगकर्ता
• तृतीय स्तर श्रेणी (स्तर 3) : हेरफेर

इस श्रेणी की निर्देशिका इस प्रकार है:

1. उपयोगकर्ता और अधिकार श्रेणी में घटनाओं को सामान्य करते समय, यह समझना महत्वपूर्ण है:
   
   • यदि विशेषाधिकार वृद्धि का उपयोग किया गया था, तो किसकी ओर से प्रक्रिया को लागू किया गया है।
     
     • फ़ील्ड: विषय [i] .assign
   • क्या क्रियाएं सफल रही हैं।
     
     • फ़ील्ड: result.status
   • रिटर्न कोड क्या है
     
     • फ़ील्ड: result.status.code
   
   
2. उपयोगकर्ता श्रेणी की घटनाओं को सामान्य करते समय, यह समझना महत्वपूर्ण है:
   
   • क्या उपयोगकर्ता की मशीन के आईपी पते, होस्ट नाम या fqdn के बारे में कोई जानकारी है।
     
     • फ़ील्ड्स: src.ip, src.hostname, src.fqdn
     • फ़ील्ड्स: dst.ip, dst.hostname, dst.fqdn
   • जिसके तहत उपयोगकर्ता जुड़ा हुआ खाता।
     
     • फ़ील्ड्स: विषय [i] .name, ऑब्जेक्ट [i] .name
   • क्या ओएस में उनके खाते के बारे में कोई जानकारी है।
     
     • फ़ील्ड: विषय [i] .osname, ऑब्जेक्ट [i] .osname
   • क्या कोई डोमेन खाता जानकारी है?
     
     • फ़ील्ड्स: विषय [i] .domain, ऑब्जेक्ट [i] .domain
   • क्या उपयोगकर्ता के आवेदन के बारे में कोई जानकारी है
     
     • फ़ील्ड्स: विषय [i]। विषयीकरण, वस्तु [i]। विषयक
   
   
3. मैनिपुलेशन श्रेणी में घटनाओं को सामान्य करते समय, यह समझना महत्वपूर्ण है:
   
   • ऑपरेशन का प्रकार।
     
     • फ़ील्ड: इंटरैक्शन। टाइप
   • क्या बदल गए हैं?
     
     • फ़ील्ड: ऑब्जेक्ट [i] .name, ऑब्जेक्ट [i] .type - जब खाते बदलते हैं
     • फ़ील्ड: संसाधन [i] .name, संसाधन [i] .type - संसाधनों में बदलते समय
   • क्या बदल गए हैं?
     
     • फ़ील्ड: ऑब्जेक्ट [i] .modify
     • फ़ील्ड: संसाधन [i] .modify
   • यदि ऑपरेशन एक संसाधन पर था, तो इसका मालिक कौन है।
     
     • फ़ील्ड: संसाधन [i] .owner

हमने इस गाइड को इसके गठन के सिद्धांत को प्रदर्शित करने के लिए दिया है, इसलिए यह सटीक और पूर्ण होने का दिखावा नहीं करता है।

नतीजतन, इस पद्धति द्वारा सामान्यीकृत घटना इस तरह दिखाई देती है:


कार्यप्रणाली के तीसरे चरण में एक सामान्यीकृत घटना का एक उदाहरण।

निष्कर्ष

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

इसलिए, संक्षेप में - दृष्टिकोण में तीन चरण शामिल हैं:

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

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

---

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

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

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

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

सिएम गहराई: आउट-ऑफ-द-बॉक्स सहसंबंध। भाग 3.2। घटना सामान्यीकरण पद्धति ( यह लेख )

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

सिएम गहराई: आउट-ऑफ-द-बॉक्स सहसंबंध। भाग 5. सहसंबंध नियम विकसित करने की पद्धति