हैकिंग विशेषज्ञ चार प्रमुख प्रोटोकॉल संकल्पना का पालन करते हैं:

एथिकल हैकर क्या है?

एथिकल हैकर को “व्हाइट हैट” के रूप में भी जाना जाता है, एथिकल हैकर्स सुरक्षा विशेषज्ञ होते हैं और जो इन सुरक्षा आकलनों को करते हैं। वह जो सक्रिय कार्य करते हैं, वह संगठन की सुरक्षा स्थिति को बेहतर बनाने में मदद करता है। संगठन या आईटी संपत्ति के मालिक से पूर्व अनुमोदन के साथ, एथिकल हैकिंग का मिशन दुर्भावनापूर्ण हैकिंग के विपरीत है।

एथिकल हैकिंग की प्रमुख अवधारणाएं क्या हैं?

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

एथिकल हैकर्स दुर्भावनापूर्ण हैकर्स से कैसे भिन्न हैं?

एथिकल हैकर्स अपने ज्ञान का उपयोग संगठनों की तकनीक को सुरक्षित और बेहतर बनाने के लिए करते हैं। वे कमजोरियों की तलाश में इन संगठनों को एक आवश्यक सेवा देतें हैं ताकि जिससे सुरक्षा भंग हो सकती है।

एक एथिकल हैकर संगठन को पहचानी गई कमजोरियों की रिपोर्ट करता है। इसके अलावा, वे उपचारात्मक सलाह प्रदान करते हैं। कई मामलों में, संगठन की सहमति से, एथिकल हैकर कमजोरियों को पूरी तरह से हल करने के लिए पुन: परीक्षण किया जाता है।

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

एक एथिकल हैकर को कौन से प्रमाणपत्र प्राप्त करने चाहिए?

एक एथिकल हैकर के पास कंप्यूटर कौशल की एक विस्तृत श्रृंखला होती है। वे अक्सर एथिकल हैकिंग डोमेन के किसी विशेष क्षेत्र में से विषय वस्तु विशेषज्ञ (एसएमई) बनने के विशेषज्ञ होते हैं।

सभी एथिकल हैकर्स के पास होना चाहिए:

• स्क्रिप्टिंग भाषाओं में विशेषज्ञता।
• ऑपरेटिंग सिस्टम में प्रवीणता।
• नेटवर्किंग की पूरी जानकारी।
• सूचना सुरक्षा के सिद्धांतों में एक ठोस आधार होना चाहिए।
• कुछ सबसे प्रसिद्ध प्रमाणपत्रों में शामिल हैं:
• ईसी काउंसिल: सर्टिफाइड एथिकल हैकिंग सर्टिफिकेशन
• आक्रामक सुरक्षा प्रमाणित पेशेवर (OSCP) प्रमाणन
• कॉम्पटिया सुरक्षा
• सिस्को की सीसीएनए सुरक्षा
• सैन्स जीआईएसी

हैकिंग किन समस्याओं की पहचान करती है?

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

एथिकल हैकर्स द्वारा खोजी गई कुछ सबसे आम कमजोरियां यह हैं :

• इंजेक्शन हमले
• टूटा हुआ प्रमाणीकरण
• सुरक्षा गलत कॉन्फ़िगरेशन
• ज्ञात कमजोरियों वाले घटकों का उपयोग
• संवेदनशील डेटा एक्सपोजर

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

एथिकल हैकिंग की कुछ सीमाएँ क्या हैं?

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

प्रतिबंधित तरीके: कुछ संगठन विशेषज्ञों में से ऐसे परीक्षण मामलों से बचने के लिए कहते हैं जो सर्वर को क्रैश की ओर ले जाते हैं (उदाहरण के लिए, इनके (DoS) हमले)।

नकारात्मक इंजीनियरिंग क्या है?

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

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

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

यह विनाशकारी विफलता की कहानी नहीं है। वास्तव में, मुझे यकीन है कि इसे पढ़ने वाला कोई भी इंजीनियर इस विशेष मुद्दे को हल करने के अनगिनत तरीकों के बारे में सोच सकता है। लेकिन कुछ इंजीनियरों को हर किनारे के मामले पर पहले से विचार-मंथन करने के लिए समय का एक अच्छा उपयोग मिलेगा – और न ही अरबों संभावित विफलताओं का लगातार अनुमान लगाना संभव है। वैसे भी, इंजीनियरों के लिए नई त्रुटियों का सपना देखे बिना चिंता करने के लिए पर्याप्त दबाव वाले मुद्दे हैं।

इसलिए, यहाँ समस्या यह नहीं थी कि कोई त्रुटि हुई। सबसे परिष्कृत बुनियादी ढांचे में भी हमेशा त्रुटियां होंगी। असली समस्या यह थी कि इसे हल करने के लिए टीम के विकल्प कितने सीमित थे। एक महत्वपूर्ण व्यावसायिक मुद्दे और एक भ्रामक कारण का सामना करते हुए, उन्हें यह सुनिश्चित करने के प्रयास में समय, प्रयास और प्रतिभा बर्बाद करने के लिए मजबूर किया गया था कि यह एक अप्रत्याशित विचित्रता फिर से अपना सिर नहीं उठाएगी।

नकारात्मक इंजीनियरिंग “बीमा कोड के रूप में” होती है

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

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

नकारात्मक इंजीनियरिंग क्यों? क्योंकि सामान होता है

बड़ी कंपनियों के लिए अपने डेटा स्टैक के परिष्कार की घोषणा करना प्रचलन में है। लेकिन सच्चाई यह है कि अधिकांश टीमें – यहां तक ​​​​कि परिष्कृत विश्लेषिकी का प्रदर्शन करने वाली – अपेक्षाकृत सरल स्टैक को नियोजित करती हैं जो महत्वपूर्ण संसाधन बाधाओं के तहत किए गए व्यावहारिक निर्णयों की एक श्रृंखला का उत्पाद हैं। इन इंजीनियरों के पास अपने व्यावसायिक उद्देश्यों को प्राप्त करने और हर विफलता मोड पर विचार करने के लिए समय की विलासिता नहीं है।

इसके अलावा, इंजीनियरों को विफलता से निपटने से नफरत है, और कोई भी वास्तव में अपने स्वयं के कोड के विफल होने की उम्मीद नहीं करता है। इस तथ्य के साथ मिश्रित कि नकारात्मक इंजीनियरिंग मुद्दे अक्सर सबसे सांसारिक सुविधाओं से उत्पन्न होते हैं – पुन: प्रयास, शेड्यूलिंग, और इसी तरह – यह समझना आसान है कि इंजीनियरिंग टीम इस तरह के काम को गलीचा के नीचे स्वीप करने या इसे किसी और की समस्या के रूप में मानने का फैसला क्यों कर सकती है। . यह समय और प्रयास के लायक नहीं लग सकता है।

अपनी उत्पादकता वापस पाएं

किसी अन्य नाम से “नकारात्मक इंजीनियरिंग” अभी भी उतना ही निराशाजनक है – और इसके कई अन्य नाम हैं। मैंने हाल ही में आईबीएम के एक पूर्व इंजीनियर से बात की, जिन्होंने मुझे बताया कि, 90 के दशक में, आईबीएम की रेडबुक में से एक ने कहा था कि सॉफ़्टवेयर के किसी भी टुकड़े के लिए “खुश पथ” में उसके कोड का 20 प्रतिशत से कम शामिल था; बाकी त्रुटि प्रबंधन और लचीलापन के लिए समर्पित था। यह उस समय के अनुपात को दर्शाता है जब आधुनिक इंजीनियर नकारात्मक इंजीनियरिंग मुद्दों पर खर्च करने की रिपोर्ट करते हैं – उनके काम के घंटों का आश्चर्यजनक 90 प्रतिशत तक।

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