क्या IoT उपकरणों के सुरक्षा स्तर को इंगित करने के लिए कोई प्रमाण पत्र है?

Question

क्या IoT उपकरणों के लिए कोई विश्वसनीय प्रमाण पत्र है, जिसका उपयोग इन उपकरणों की सुरक्षा प्रदान करने के लिए किया जा सकता है? ¹

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

यदि कोई मौजूदा मानक नहीं है, तो क्या ऐसे मानक बनाने के लिए आशाजनक पहल की जाती है?

---

_{1: डिस्क्लेमर: यह इस एरिया 51 पर आधारित है जो उस यूजर से लगता है जो प्रतिबद्धता मंच में साइट के लिए प्रतिबद्ध नहीं था। मैं इसे साइट के दायरे को परिभाषित करने में मदद करने के लिए पोस्ट करना चाहता हूं।}

Answer 1

उल (पूर्व में अंडरराइटर लेबोरेटरीज) यह प्रमाणित करने के लिए साइबरस्पेस एश्योरेंस प्रोग्राम प्रदान करती है कि इंटरनेट ऑफ थिंग्स डिवाइस, उनकी राय में, सबसे बड़े खतरों से सुरक्षित है।

एएलएस टेक्नीका के अनुसार, उल को उनकी प्रमाणन प्रक्रियाओं में बहुत सम्मान प्राप्त होता है :

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

उल उनके प्रमाणन का वर्णन करते हैं:

• सभी इंटरफेस पर शून्य दिन भेद्यता की पहचान करने के लिए उत्पादों की फ़ज़ी टेस्टिंग
• उन उत्पादों पर ज्ञात भेद्यता का मूल्यांकन जो सामान्य भेद्यता गणना (CVE) योजना का उपयोग करके पैच नहीं किया गया है
• उत्पादों पर ज्ञात मैलवेयर की पहचान
• सॉफ़्टवेयर की कमजोरियों के लिए स्टेटिक सोर्स कोड विश्लेषण, कॉमन वेकनेस एनुमरेशंस (CWE) द्वारा पहचाना गया
• सामान्य कमजोरी गणना (सीडब्ल्यूई), ओपन सोर्स सॉफ्टवेयर और तीसरे पक्ष के पुस्तकालयों द्वारा पहचाने जाने वाले सॉफ्टवेयर कमजोरियों के लिए स्टेटिक बाइनरी विश्लेषण
• सुरक्षा जोखिम को कम करने वाले उत्पादों में उपयोग के लिए पहचाने जाने वाले विशिष्ट सुरक्षा नियंत्रण [...]
• अन्य परीक्षणों में पहचाने गए दोषों के आधार पर उत्पादों की संरचित पैठ परीक्षण
• उत्पादों में डिज़ाइन किए गए उत्पाद सुरक्षा शमन का जोखिम मूल्यांकन।

हालाँकि, सटीक प्रक्रिया जिसमें UL उपकरणों की जांच अस्पष्ट है (जब तक कि आप विनिर्देशों के पूर्ण सेट को खरीदने के लिए भुगतान नहीं करते हैं), Ars Technica note के रूप में (और आलोचना करें):

जब Ars ने मानक पर करीब से नज़र डालने के लिए UL 2900 डॉक्स की एक प्रति का अनुरोध किया, तो UL (जिसे पूर्व में अंडरराइटर लेबोरेटरीज के रूप में जाना जाता था) में गिरावट आई, यह दर्शाता है कि अगर हम कॉपी-रिटेल मूल्य, पूर्ण के लिए £ 600/800 800 खरीदना चाहते हैं। सेट-हम ऐसा करने के लिए स्वागत करते थे। स्वतंत्र सुरक्षा शोधकर्ता भी हैं, हमें यह मानकर चलना चाहिए कि यूएल खुदरा ग्राहक बनें।

हालांकि यूएल का सम्मान किया जाता है, हम यह नहीं मान सकते हैं कि उनका प्रमाणन विशेष रूप से सुरक्षा के संदर्भ में ध्वनि है, हालांकि यह मूल प्रश्न को संतुष्ट नहीं करता है।

दुर्भाग्य से, मैं सुरक्षा के लिए कोई भी खुला मानकों / प्रमाणपत्र नहीं पा सका, हालांकि यह संभव है क्योंकि गैर-लाभकारी संघ के लिए आवश्यक संसाधन बहुत बड़े होंगे।

Answer 2

मैं Aurora0001 के उत्तर में जोड़ना चाहता हूं कि हम केवल ज्ञात खतरों से रक्षा कर सकते हैं।

हाल ही में, हमने हार्डवेयर के खिलाफ स्पेक्टर और मेलडाउन हमलों को देखा है । जबकि इंटेल CPU का आमतौर पर IoT उपकरणों में उपयोग नहीं किया जाता है, हम संभवतः भविष्य में IoT हार्डवेयर के साथ सुरक्षा समस्याओं का पता लगाएंगे। इससे पहले हमने देखा Rowhammer और Heartbleed पर प्रणाली स्तरीय कीड़े, प्रणाली की बड़ी संख्या को प्रभावित करने के रूप में। जैसा कि IoT बढ़ता है, मेरा मानना ​​है कि इस तरह की कमजोरियों को देखने के लिए यह अधिक सामान्य जगह होगी।

इसलिए मैं सुरक्षा प्रमाणपत्रों पर कम ध्यान दूंगा, और अधिक के बारे में:

• खुलापन, ताकि तीसरे पक्ष सॉफ्टवेयर का मूल्यांकन कर सकें।
• चरणबद्ध समर्थन जीवनकाल, जहां निर्माता सुरक्षा अपडेट की गारंटी देता है
• डिफ़ॉल्ट सेटिंग के रूप में स्वत: उन्नयन सहित उन्नयन।

यदि एक उपकरण को लंबे समय तक समर्थन के तहत कहा जाता है, और नए रिलीज होने पर सॉफ़्टवेयर को ऑटो-अपडेट करने में चूक हो जाती है, तो सुरक्षा समस्याओं का प्रभाव कम हो जाएगा। प्रमाणन केवल आपको बताएगा कि उत्पाद को भेज दिए जाने पर कोई ज्ञात सुरक्षा बग नहीं था।

Comments

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

— गिल्स एसओ- बुराई को रोकना '

मुद्दा यह है कि कीड़े असंभावित स्थानों (सीपीयू) में पाए जा सकते हैं, और अच्छी तरह से ज्ञात सॉफ्टवेयर (हार्टलेड) में, इस प्रकार हमें सॉफ्टवेयर को पैच करने और अपडेट करने की आवश्यकता होती है । लेकिन हाँ - चुनने के लिए बगों की अधिकता है।

— विदरालो

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

— Helmar

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

— गिल्स एसओ- बुराई को रोकना '

@ मैं सहमत हूँ कि कोई केवल सॉफ्टवेयर विकास की गुणवत्ता प्रक्रियाओं या ऐसा कुछ प्रमाणित कर सकता है। हर सॉफ्टवेयर संस्करण को प्रमाणित करना वास्तव में एक विकल्प नहीं है।

— Helmar