उत्पाद सुरक्षा में खराब तरीके
(cisa.gov)स्वयं उत्पाद में
memory-safe नहीं होने वाली भाषाएँ (C, C++ आदि)
जहाँ तक संभव हो memory-safe भाषाओं का उपयोग करें, और जो मौजूदा प्रोग्राम ऐसे नहीं हैं उन्हें 2025 के अंत तक क्रमिक रूप से बदल देना चाहिए।
SQL statements को सीधे चलाना
parameterized queries, prepared statements या ORM का उपयोग करें।
operating system commands को सीधे चलाना
यूज़र का इनपुट स्वयं command नहीं होना चाहिए। command को सीधे चलाने के बजाय built-in library functions का उपयोग करें, या इनपुट में केवल अंग्रेज़ी अक्षर/संख्या/underscore की अनुमति दें।
बहुत ज़्यादा प्रसिद्ध passwords का उपयोग
इसे जहाँ तक संभव हो, नीचे दिए गए तरीकों से टालना चाहिए।
- शुरुआत से ही unique passwords प्रदान करें।
- installation के दौरान यूज़र से एक मज़बूत password बनवाना अनिवार्य करें।
- MFA की तरह password पर time limit लागू करें।
- पक्का credential पाने के लिए physical access आवश्यक करें।
- अभियान चलाएँ या पहले से अधिक सुरक्षित authentication तरीकों पर स्विच करें।
ज्ञात vulnerabilities को अनदेखा करना
उस पेज पर सूचीबद्ध vulnerabilities को "सभी" रोका जाना चाहिए। जब नई vulnerabilities रिपोर्ट हों, तो उन्हें समय पर ठीक किया जाना चाहिए, और जो यूज़र fixed version पर update नहीं करते उन्हें चेतावनी दी जानी चाहिए।
vulnerabilities वाली open source libraries
जिन libraries का उपयोग हो रहा है, उनके बारे में ज़िम्मेदारी से सूचना दें और योगदान करें। इसमें नीचे दिए गए कदम भी शामिल हैं।
- SBOM तैयार करना: यह दिखाता है कि software कौन-कौन सी libraries का उपयोग करता है।
- जिन open source libraries पर आप निर्भर हैं, उनके लिए लागू होने वाली बातें
- security inspection करें।
- ऐसे अच्छे projects चुनें जो निरंतर चल रहे हों, अच्छी तरह संरक्षित हों, और अच्छे से maintain किए जाते हों। ऐसे security principles का पालन करना भी अच्छा है।
- यह लगातार जाँचना चाहिए कि कहीं कोई well-known vulnerability तो नहीं है।
- vendor के पास copy पहले से होनी चाहिए, और unverified जगहों से update नहीं करना चाहिए।
- नई major version में update करने या security patches लेने की लागत को ध्यान में रखना चाहिए।
अगर कोई vulnerability उत्पाद को प्रभावित नहीं करती, तो सार्वजनिक रूप से बताना चाहिए कि वह vulnerability क्यों प्रभाव नहीं डालती।
vulnerable या अज्ञात cryptographic algorithms (TLS 1.0/1.1, DES, MD5 आदि)
नवीनतम algorithms का उपयोग करना चाहिए। इसके अतिरिक्त NIST guidance के अनुसार standardized post-quantum cryptography algorithms के लिए भी तैयारी करनी चाहिए।
source code में शामिल secret keys
Secret Manager का उपयोग करके यह सुनिश्चित करना चाहिए कि program secret keys को सुरक्षित रूप से retrieve कर सके। साथ ही source code में secret keys की जाँच भी करनी चाहिए।
security features में
MFA का समर्थन न होना (केवल passkey support होने को भी शामिल किया गया है)
ऐसी चीज़ों को छोड़कर जहाँ देरी खतरनाक हो सकती है, जैसे emergency room medical devices, डिफ़ॉल्ट रूप से MFA को स्वयं बनाना या external authenticator का उपयोग करना चाहिए। यह administrators के लिए अनिवार्य होना चाहिए, और administrators को इसे संगठन के भीतर यूज़र्स पर लागू करना चाहिए।
intrusion evidence न देना
- एक बेहद बुनियादी feature के रूप में settings में बदलाव या उनकी viewing, login history, और information access से जुड़े logs बनाए जाने चाहिए।
- cloud providers के मामले में, बिना अतिरिक्त लागत के कम से कम 6 महीने तक ऐसे logs को सुरक्षित रखना चाहिए और उन्हें यूज़र के लिए देखने योग्य बनाना चाहिए।
organizational processes और policies में
CVE जारी न करना
गंभीर या बड़े प्रभाव वाली vulnerabilities को तुरंत सार्वजनिक किया जाना चाहिए।
vulnerability disclosure process (VDP) को सार्वजनिक न करना
नीचे जैसी policies सार्वजनिक करनी चाहिए।
- आम जनता को testing की अनुमति
- good-faith effort करने वाले लोगों के खिलाफ कानूनी कार्रवाई न करने का वादा
- रिपोर्ट करने के लिए स्पष्ट channel
- CVD(Coordinated Vulnerability Disclosure) best practices और international standards
रिपोर्ट की गई vulnerabilities को समय पर, risk level के क्रम में ठीक किया जाना चाहिए।
(on-premises के मामले में) अस्पष्ट support period
support period को स्पष्ट रूप से बताना चाहिए, और उस अवधि के दौरान security updates प्रदान किए जाने चाहिए।
- KakaoTalk में one-click exploit
- GN⁺: NIST (अमेरिकी National Institute of Standards and Technology), passwords में विशेष character composition requirements पर रोक
- White House ने developers से C और C++ से बचने और 'memory-safe' languages का उपयोग करने की अपील की
- मेरी car को hack करना: Hyundai Ioniq: source code में Google से खोजी जा सकने वाली RSA ciphertext मिली
7 टिप्पणियां
सुरक्षा बस एक पल की चूक है,,! (लगता है यह बात मैंने सेना में देखी थी)
हिम्मत मत हारो!
लगता है फिर से यह बात चल रही है कि ORM का इस्तेमाल नहीं करना चाहिए..
ORM की जगह Prepared Statement का इस्तेमाल करें।
zzz
हर चीज़ के कुछ सिद्धांत होते हैं, बस उन्हें निभाना मुश्किल होता है...
मुझे यह पसंद है, मैं सहमत हूँ
यूज़र से मज़बूत पासवर्ड बनाने की मांग करना != यह अनिवार्य करना कि उसमें special character, अंग्रेज़ी के uppercase और lowercase अक्षर, और नंबर ज़रूर हों
सिर्फ़ लंबाई ठीक-ठाक अधिक होना ही उसे मज़बूत पासवर्ड बना देता है.