SolarWinds हैक से हमने कुछ नहीं सीखा
SolarWinds breach के वर्षों बाद, टिप्पणीकारों का तर्क है कि software security की मूल संरचनात्मक समस्याएँ अब भी बड़े पैमाने पर अनसुलझी हैं, खासकर software supply chain के आसपास। वे dependencies की verification के लिए कमजोर या छोड़े गए mechanisms, GitHub जैसे केंद्रीकृत platforms पर गहरी निर्भरता, और उन आर्थिक प्रोत्साहनों को उजागर करते हैं जो कठोर security के बजाय तेज़ feature delivery को बढ़ावा देते हैं। प्रस्तावित समाधानों में बेहतर compartmentalization और capability-based systems से लेकर confidential computing और मज़बूत regulatory या liability regimes तक शामिल हैं, लेकिन कई लोगों को संदेह है कि बिना महत्वपूर्ण सांस्कृतिक और आर्थिक बदलाव के ये व्यापक रूप से अपनाए जा सकेंगे।
पैकेज साइनिंग, रिपॉज़िटरीज़, और डिपेंडेंसी ट्रस्ट
- कई टिप्पणियाँ PyPI द्वारा PGP सिग्नेचर हटाने और प्रमुख पैकेज रिपॉज़िटरीज़ में मज़बूत साइनिंग/वेरिफिकेशन की व्यापक कमी की आलोचना करती हैं।
- कुछ लोग PyPI के बजाय distro packaging (.deb) और local mirrors पर निर्भर करते हैं, और बेहतर signature checking तथा broken packages को patch करने की बात करते हैं।
- Enterprise tools (जैसे JFrog/Sonatype जैसे) जो ecosystems के across components को hash और tag करते हैं, उपयोगी stopgaps माने जाते हैं, लेकिन public repos में व्यापक रूप से उपलब्ध नहीं हैं।
- GitHub पर CI, package sources, और code hosting के de facto backbone के रूप में भारी निर्भरता को एक systemic risk माना जाता है।
स्कैनिंग, यूनिवर्सल टूल्स, और उनकी सीमाएँ
- binaries या source का supply-chain attacks के लिए विश्लेषण करने वाली सेवाओं में रुचि है, लेकिन कई लोग उनकी प्रभावशीलता और scalability पर संदेह करते हैं।
- “संदिग्ध” package behavior का पता लगाने वाले tools (static/dynamic analysis) मौजूद हैं और सक्रिय रूप से विकसित किए जा रहे हैं।
- एक universal package manager को बड़े पैमाने पर अव्यवहार्य माना जाता है।
अर्थशास्त्र, प्रोत्साहन, और दायित्व
- टिप्पणीकार इस बात पर ज़ोर देते हैं कि संगठन न्यूनतम लागत पर “काफी अच्छी” security चाहते हैं; वास्तविक hardening को आर्थिक रूप से अनाकर्षक माना जाता है।
- जुर्माने और नियामकीय दबाव मदद कर सकते हैं, लेकिन ये बड़े vendors को और मज़बूत कर सकते हैं तथा छोटी कंपनियों और open source को नुकसान पहुँचा सकते हैं।
- कुछ का तर्क है कि हमें प्रणालियों को compartmentalization और reduced blast radius के जरिए compromised software को सहने योग्य बनाना चाहिए, यह मानकर नहीं चलना चाहिए कि सभी software को सुरक्षित बनाया जा सकता है।
क्षमताएँ, सैंडबॉक्सिंग, और OS डिज़ाइन
- एक standardized capability model आदर्श माना जाता है, लेकिन राजनीतिक और तकनीकी रूप से इसके संभव होने की संभावना कम है, और vendors द्वारा इसके दुरुपयोग की आशंका है (जैसे business models की रक्षा के लिए capabilities को फिर से परिभाषित करना)।
- अन्य लोग compartmentalization और redundancy पर ज़ोर देते हैं, safety-critical systems से तुलना करते हुए जहाँ एकल विफलता पूरे सिस्टम को नष्ट नहीं करती।
- मोबाइल permission models (iOS/Android), side-loading, और locked-down “secure” platforms तथा user freedom के बीच trade-off पर चर्चा होती है।
Supply Chain Security और Attestation
- कुछ लोग hardened, isolated build systems और standardized metadata/attestation (जैसे in-toto, Witness) का प्रस्ताव रखते हैं ताकि supply-chain steps को track और verify किया जा सके।
- Confidential computing with remote attestation को एक ऐसे तरीके के रूप में चर्चा की जाती है जिससे साबित किया जा सके कि artifacts को specific source और specific tools से बनाया गया था, यहाँ तक कि compromised hosts पर भी।
- यह attacks को compilers और build tools की ओर मोड़ देता है, जिससे memory-safe compilers और reproducible builds में रुचि बढ़ती है।
ऑपरेशनल वास्तविकता और अनुपालन
- प्रैक्टिशनर नोट करते हैं कि advanced threats के लिए prevention सीमित है; आधुनिक practice EDR, logging, SIEM, और compromise के बाद के behavior का पता लगाने पर केंद्रित है।
- corporate networks को messy बताया जाता है, जिनमें कई legacy constraints और user-experience trade-offs होते हैं।
- Security questionnaires और checkbox-style compliance को पुराना और cloud-native architectures के साथ असंगत कहा जाता है, हालांकि इन्हें सरल बनाने के प्रयास भी हो रहे हैं।