एक सॉफ्टवेयर के अनोखे पहलू क्या हैं किसी सॉफ़्टवेयर भेद्यता पर हमले / उपकरण का जीवनचक्र?


10

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

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

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

मुझे लगता है कि जीवन-चक्र कुछ इस तरह होगा:

  1. सुरक्षा में अंतर खोजें
  2. सुरक्षा में अंतर गैप
  3. प्रोक्योर पेलोड
  4. पेलोड का उपयोग करें

जब उत्पाद का उद्देश्य सुरक्षा को भंग करना है तो सॉफ़्टवेयर के विकास जीवन-चक्र के लिए किस प्रकार के अंतर (यदि कोई हो) हैं?


4
जो कहता है कि जो भी हैकिंग में कोई औपचारिकता है
शाफ़्ट सनकी

1
डांग, चार अच्छे उत्तर पहले से ही। बस एक को चुनना कठिन होता जा रहा है।
डेविड काकज़ेंस्की

@DavidKaczynski आप सूचना सुरक्षा पर यह पूछने पर भी विचार कर सकते हैं , जो वास्तव में विभिन्न प्रकार के सॉफ़्टवेयर डिज़ाइन करने वालों का दृष्टिकोण प्राप्त कर सकते हैं। और वहाँ बड़े मतभेद, सुरक्षा आवश्यकताओं के आधार पर कर रहे हैं ...
शौकीन चावला

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

1
@DavidKaczynski लेकिन मेरी बात यह है कि यह है है या बल्कि, एक प्रकार के विकास एक अन्य प्रकार से अलग है - स्वाभाविक अलग। उदाहरण के तौर पर टेरी के जवाब को देखें, और आगे के वायरस की तुलना करें, और फिर से शून्य-दिनों तक, और फिर से स्टक्सनेट पर जाएं, और ... कुछ को ठीक से इंजीनियर किया जाएगा, कुछ को रात भर बाहर फेंक दिया जाता है, अलग-अलग संदर्भ और आवश्यकताओं पर निर्भर करता है ।
AVID

जवाबों:


7

आप किस प्रकार के कोड के बारे में बात कर रहे हैं?

हैकिंग की प्रक्रिया में उपयोग किए जाने वाले कई सुरक्षा उपकरण हैं, जिनमें नैम्प , स्कैल्मप , नेसस और कई अन्य जैसे स्कैनर शामिल हैं। मुझे लगता है कि वे किसी भी अन्य अनुप्रयोगों की तरह एक ही प्रकार के सॉफ़्टवेयर जीवन-चक्र होंगे।

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


@ एवीडी के साथ एक चर्चा के बाद, मैं कुछ बिंदुओं में जोड़ना चाहूंगा।

यह विशिष्ट स्थितियों के लिए बहुत अलग होगा।

शून्य-दिन के पैच होने से पहले कुछ शोषण कोड विंडो को ध्यान में रखते हुए निकाले जा सकते हैं। अन्य कारणों से भी कोड डाला जा सकता है। देखें: CRIME - BEAST उत्तराधिकारी को कैसे हराया जाए? इस के एक महान उदाहरण के लिए। एक व्यक्ति ने अपनी बात जल्दी साबित करने के लिए PoC कोड का एक टुकड़ा लिखा। इस तरह के कोड के लिए कोई सॉफ्टवेयर जीवन चक्र पद्धति पर ध्यान नहीं दिया जाता है।

Stuxnet या FLAME जैसे हथियार वाले मैलवेयर शायद करते हैं। Metasploit जैसे पैकेज्ड सॉफ्टवेयर।

तो सही जवाब है ... यह निर्भर करता है।


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

3

मैं यह नहीं देखता कि उत्पाद के उद्देश्य के आधार पर कोई विशेष रूप से अलग-अलग विकास जीवन-चक्र क्यों होना चाहिए।

सुरक्षा के लिए विकसित किए गए सॉफ़्टवेयर में किसी भी अन्य प्रकार के सॉफ़्टवेयर के रूप में लंबे समय तक जीवन हो सकता है और इसके लिए रखरखाव और कार्य की समान मात्रा की आवश्यकता होगी।

ऐसे सॉफ़्टवेयर के विभिन्न निर्माता अपनी आवश्यकताओं के आधार पर विभिन्न जीवन-चक्रों को अपनाएंगे।


3

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

मुझे यकीन नहीं है कि इन मॉडलों को सीधे अधिक शोध-उन्मुख परियोजनाओं पर लागू किया जा सकता है, जहां आप सवालों के जवाब देने की कोशिश कर रहे हैं या किसी सिस्टम (या सिस्टम की सुरक्षा कमजोरियों, आपके विशेष मामले में) के बारे में अधिक जानने के लिए।

मुझे संदेह होगा कि पुनरावृत्त / वृद्धिशील मॉडल, जैसे कि चुस्त तरीके और सर्पिल मॉडल एक आधार बनाने के लिए सबसे उपयोगी होंगे। प्रत्येक पुनरावृत्ति में, आप सवालों के जवाब देने या काम करने के लिए अधिक मापदंडों को परिभाषित करने की दिशा में काम कर सकते हैं, जिसमें किसी भी कोड को लिखना या शामिल करना शामिल नहीं हो सकता है। शायद विभिन्न वैज्ञानिक अनुसंधान विधियां भी एक दिलचस्प आधार प्रदान कर सकती हैं।


1

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

जाहिरा तौर पर शून्य-दिन के कारनामों के लिए एक विकासशील बाजार भी है ।


1

जीवन-काल कभी भी कोड पर निर्भर नहीं होता है। यह अन्य कारकों पर निर्भर है जैसे:

  1. समय
  2. बजट
  3. ग्राहक की प्रकृति
  4. उत्पाद की प्रकृति

आपके परिदृश्य में, एजाइल लाइफ काइल पद्धति सबसे उपयोगी होगी। कारण यह है कि आपको विकास के दौरान अपने ग्राहक को शामिल करना होगा और अपने उत्पाद की स्वीकार्य गुणवत्ता मानकों को सत्यापित करना होगा। फुर्तीली कार्यप्रणाली आपको अपने ग्राहक के फीडबैक को इकट्ठा करके और फिर धीरे-धीरे वृद्धिशील आधार पर काम करके अपने हैकिंग सॉफ्टवेयर को बेहतर बनाने में मदद करेगी ।


यह थोड़ा व्यक्तिपरक लगता है। क्या आप यह सुझाव दे रहे हैं कि अन्य जीवनचक्र विधियां ग्राहक को विकास के दौरान शामिल नहीं करती हैं या स्वीकार्य गुणवत्ता मानकों को सत्यापित करती हैं? बेशक जो फुर्तीली के लिए अद्वितीय नहीं है।
जे स्टीवंस
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.