- कंप्यूटर सुरक्षा एक ऐसा क्षेत्र है जहाँ उत्पाद, कॉन्फ़्रेंस, किताबें और क़ानून लगातार बढ़ते रहते हैं, लेकिन बार-बार की विफलताओं की जड़ में Default Permit और Enumerating Badness जैसी गलत बुनियादी मान्यताएँ हैं
- मूल समस्या यह है कि “क्या अनुमति देनी है” इसे संकीर्ण रूप से परिभाषित करने के बजाय “क्या रोकना है” उसका अंतहीन पीछा किया जाता है; और फ़ायरवॉल, code execution, और worm response में Default Deny न चुनने पर रक्षकों को हमलावरों के साथ arms race में फँसना पड़ता है
- बुरी चीज़ों की सूची बनाना 75,000 से अधिक वायरस और हर महीने 200~700 नए ख़तरों को ट्रैक करने जैसा है, इसलिए यह वास्तव में ज़रूरी लगभग 30 वैध applications को प्रबंधित करने वाले Enumerating Goodness की तुलना में कम प्रभावी है
- vulnerabilities खोजने और patch करने का तरीका, hacking को आकर्षक बनाकर उपभोग करने वाली संस्कृति, और user education पर निर्भर रणनीतियाँ—ये सब design flaws कम करने के बजाय घटना के बाद की प्रतिक्रिया दोहराती हैं
- नई तकनीक को तुरंत अपनाने के बजाय इंतज़ार कर उसे परखना अधिक सुरक्षित हो सकता है, और security practitioners को trends से ज़्यादा सामान्य समझ पर आधारित design और संदेहपूर्ण दृष्टि को प्राथमिकता देनी चाहिए
सुरक्षा विफलताओं को जन्म देने वाले “विरोधी-उत्तम विचार”
- कंप्यूटर सुरक्षा में नए उत्पाद, नई कॉन्फ़्रेंस, नई किताबें और नए क़ानून लगातार आते रहते हैं, लेकिन समस्याएँ दोहराई जाती रहती हैं
- “मूर्खतापूर्ण विचार” अच्छे विचारों के उलट दिशा में जाने वाले वे approaches हैं, जो तब पैदा होते हैं जब कोई असंभव काम करने की कोशिश करता है या वास्तविकता की अनदेखी करता है
- ऐसे approaches कभी नेक इरादे वाली गलतफहमियों से आते हैं, तो कभी जल्दी पैसा कमाने के लिए अच्छी तरह पैक किए गए उत्पादों से
- इन छह विचारों को उनकी आम उपस्थिति के क्रम में रखा गया है, और खासकर यदि आप पहले तीन से बच सकते हैं तो आप बेहतरीन सुरक्षा पेशेवरों की छोटी श्रेणी में आते हैं
1. Default Permit: डिफ़ॉल्ट अनुमति
- Default Permit वह तरीका है जिसमें जो चीज़ स्पष्ट रूप से मना नहीं की गई हो, उसे सब अनुमति दी जाती है; यह फ़ायरवॉल rules में सबसे आसानी से दिखाई देता है
- शुरुआती network administrators incoming telnet, rlogin, और FTP को ही block करते थे और बाकी सबको अनुमति देते थे
- हर नई vulnerability मिलने पर administrator को तय करना पड़ता था कि उसे block करना है या नहीं, और उन्हें compromise होने से पहले आगे निकलना पड़ता था
- 1990 के दशक के worms आने के बाद यह तरीका ख़त्म हो जाना चाहिए था, लेकिन बहुत-से networks आज भी बिना segmentation वाले खुले core architecture पर चलते हैं
- code execution में भी यही समस्या दोहराई जाती है
- user के click करते ही डिफ़ॉल्ट रूप से कुछ भी run हो जाता है, और केवल antivirus या spyware blocker के रोकने पर ही execution रोका जाता है
- व्यवहार में अक्सर इस्तेमाल होने वाले applications लगभग 15 होते हैं, और कभी-कभार इस्तेमाल होने वाले 20~30 के आसपास, फिर भी operating system डिफ़ॉल्ट रूप से virus या spyware को execute होने देता है
- E-banking security project ने उल्टा approach अपनाया
- load balancer केवल ज्ञात attacks को blackhole में भेजने के बजाय, सही URL सूची से मेल न खाने वाले सभी traffic को image और 404 page देने वाले locked server की ओर भेजता है
- यह ज्ञात attacks को ही रोकने वाला Default Permit नहीं, बल्कि सामान्य संरचना से बाहर की requests को अस्वीकार करने वाला तरीका है
- यदि आप हमलावरों के साथ arms race में हैं, तो यह संकेत है कि आप Default Permit में फँसे हुए हैं
- इसका उल्टा विचार Default Deny है, जिसे लागू करने के लिए समर्पण, सोच और समझ चाहिए, लेकिन यही बेहतर तरीका है
2. Enumerating Badness: बुरी चीज़ों की सूची बनाना
- Enumerating Badness वह तरीका है जिसमें ज्ञात बुरी चीज़ों की पूरी सूची बनाई जाती है और फिर उन्हें detect या block किया जाता है
- शुरू में, जब ज्ञात security holes कम थे, यह संभव लगता था; लेकिन लगभग 1992 से इंटरनेट की “बुरी चीज़ें” उसकी “अच्छी चीज़ों” से बहुत अधिक हो गईं
- एक सामान्य antivirus product 75,000 से अधिक viruses को जानता है
- एक व्यक्तिगत computer पर स्थापित वैध applications की संख्या लगभग 30 मानी जाती है
- यदि इन 30 वैध applications को track किया जाए और बाकी को चलने न दिया जाए, तो spyware, virus, remote-control trojans, और कम इस्तेमाल होने वाले preinstalled code-execution exploits जैसी समस्याएँ एक साथ कम की जा सकती हैं
- कुछ industry analyses के अनुसार हर महीने 200~700 नई “बुरी चीज़ें” इंटरनेट पर आती हैं
- इस आपत्ति पर कि enterprise network इतने जटिल होते हैं कि वैध applications की पहचान करना कठिन है, जवाब यह है कि यदि CTO को मोटे तौर पर भी यह नहीं पता कि तकनीक क्या कर रही है, तो capacity planning, disaster planning, और security planning कुछ भी सही तरह नहीं हो सकती
- 1994 में firewall products के log analysis ने पहले बुरी स्थितियों को खोजने का तरीका अपनाया था, लेकिन दूसरे version में Artificial Ignorance का उपयोग किया गया
- जिन logs को गैर-रोचक माना गया, उन्हें फेंक दिया गया
- जो logs बचे, उन्हें रोचक माना गया
- इस approach ने ऐसी operational conditions और errors पकड़े जिनकी पहले कल्पना भी नहीं की गई थी
- antivirus, intrusion detection, intrusion prevention, application security, और deep packet inspection firewalls अक्सर इसी तरीके पर निर्भर करते हैं
- यदि किसी system को नियमित signature updates चाहिए हों, या वह पहली बार दिखने वाले worm को गुजरने दे, तो यह Enumerating Badness का लक्षण है
- इसका उपचार Enumerating Goodness है, लेकिन माना जाता है कि operating systems में software-level control के लिए ऐसा समर्थन बहुत कम है
3. Penetrate and Patch: घुसपैठ करो और patch करो
- Penetrate and Patch वह चक्र है जिसमें बाहर से firewall, software, website आदि पर हमला कर खामियाँ ढूँढी जाती हैं, फिर उन्हें ठीक किया जाता है, और फिर नई खामियाँ खोजी जाती हैं
- यह तरीका बेहतर design वाले systems नहीं बनाता, बल्कि trial-and-error से कठोर किए गए systems बनाता है
- Richard Feynman का Personal Observations on the Reliability of the Space Shuttle इस बारे में पढ़ने लायक सामग्री है कि जटिल systems की reliability कैसे हासिल की जानी चाहिए
- इसका मुख्य संदेश लगभग यह है: “यदि कोई system hackable होने के लिए design नहीं किया गया है, तो उसे hackable नहीं होना चाहिए”
- vulnerability disclosure और patch updates का चलन भी इसी approach पर आधारित है
- vulnerability researchers मानते हैं कि वे hackers से पहले छेद खोजकर और उन्हें ठीक करवाकर समुदाय की मदद कर रहे हैं
- vendors मानते हैं कि वे hackers और worm authors के इस्तेमाल करने से पहले patch जारी कर सही काम कर रहे हैं
- लेकिन यदि code शुरू से ही सुरक्षित और भरोसेमंद ढंग से design किया गया हो, तो vulnerabilities ढूँढना एक उबाऊ और कम-इनाम वाला काम बन जाएगा
- यदि Internet Explorer में 10 साल तक हर महीने 2~3 security bugs आती रहीं, तो यह मानना कठिन है कि Penetrate and Patch प्रभावी था
- PostFix और Qmail जैसे कुछ applications को privileges और processing को modularize और compartmentalize करने के लिए design किया गया था, इसलिए माना जाता है कि उनका security bug history बहुत कम रहा
- penetration testing की भी यही सीमाएँ हैं
- जिन networks का मूल design या security practices ही गलत हों, वे कई बार penetration testing के बाद भी बार-बार hack होते रहेंगे
- जिन networks को शुरू से ही केवल विशेष दिशा, विशेष traffic, और सावधानी से configured servers को ही allow करने के लिए design किया गया हो, वहाँ सामान्य penetration testing अर्थहीन हो सकती है
- यदि आप हर बार “इस हफ़्ते के bug” के प्रति vulnerable रहते हैं, तो आप Penetrate and Patch में फँसे हुए हैं
- software और systems को secure by design होना चाहिए, और उन्हें faults को ध्यान में रखकर design किया जाना चाहिए
4. Hacking is Cool: हैकिंग कूल है
- Hacking is Cool उस संस्कृति की आलोचना है जिसमें hackers को stock options, किताबें, courses, और महँगे penetration tests के ज़रिए पुरस्कृत या महिमामंडित किया जाता है
- Donn Parker के अनुसार remote computing ने अपराध में physical proximity की आवश्यकता हटा दी है, और anonymity तथा victim से आमने-सामने संपर्क न होने से अपराध की भावनात्मक बाधा कम हो गई है
- hacking एक तकनीकी समस्या से अधिक सामाजिक समस्या के करीब है
- इंटरनेट ने सामाजिक रूप से कम जुड़ाव रखने वाले लोगों को गतिविधि का नया क्षेत्र दिया
- जब security practitioners hackers को hero बना देते हैं, तो वे परोक्ष रूप से hacking को प्रोत्साहित करते हैं
- media कभी-कभी hackers को “whiz kids” या “brilliant technologists” के रूप में चित्रित करता है
- security practitioners का hacking techniques सीखना भी इस विचार का हिस्सा माना गया है
- exploits और उनका इस्तेमाल उस vulnerability के patch होते ही जल्दी पुराने पड़ जाते हैं
- इससे पेशेवर क्षमता Penetrate and Patch वाले arms race पर निर्भर हो जाती है
- hackable systems ढूँढना सीखने से अधिक समझदारी hack-resistant security systems design करना सीखने में है
- अनुमान है कि “Hacking is Cool” 10 साल के भीतर गायब हो जाएगा, लेकिन उसके उलट “Good Engineering is Cool” के आने के संकेत नहीं दिखते
5. Educating Users: users को शिक्षित करना
- Educating Users लोगों पर लागू किया गया Penetrate and Patch जैसा विचार है
- शिक्षा अपने आप में अच्छी लगती है, लेकिन यदि यह प्रभावी होती, तो उसका असर अब तक दिख जाना चाहिए था
- कई अध्ययनों में यह पाया गया कि काफ़ी प्रतिशत users एक candy के बदले अपना password दे देते हैं
- Anna Kournikova worm को ऐसे उदाहरण के रूप में पेश किया जाता है जो दिखाता है कि मानवता का लगभग आधा हिस्सा किसी भी चीज़ पर click कर देगा, अगर वह किसी आधी-मशहूर महिला की nude photo जैसी लगे
- यदि user education को रणनीति बनाया जाए, तो users को हर हफ़्ते “patch” करना पड़ सकता है
- असली सवाल यह नहीं है कि “क्या users को और सुरक्षित बनने के लिए प्रशिक्षित किया जा सकता है”, बल्कि यह है कि “आख़िर users को शुरू से ही प्रशिक्षित करने की ज़रूरत क्यों पड़नी चाहिए”
- users को executable attachments मिलते ही क्यों हैं
- users ऐसे bank से आए email की अपेक्षा ही क्यों करें, जहाँ उनका account भी नहीं है
- attachments और phishing का जवाब भी Default Permit की समस्या से जुड़ा है
- यदि सभी users को email attachments प्राप्त करने की अनुमति है, तो इसका मतलब है कि भेजी गई हर चीज़ को डिफ़ॉल्ट रूप से अनुमति दी जा रही है
- बेहतर तरीके में सभी attachments को quarantine किया जा सकता है, executables को delete किया जा सकता है, और केवल स्वीकृत file types को staging server पर रखा जा सकता है
- users फिर SSL-enabled browser से login करके files ले सकते हैं, और password requirement कई worm propagation mechanisms को तुरंत कमज़ोर कर सकती है
- MIMEDefang जैसे free tools का उपयोग incoming email से attachments अलग कर उन्हें user-specific directories में रखने और mail के भीतर attachment को संबंधित URL से बदलने के लिए किया जा सकता है
- एक छोटे security startup को चलाते समय, जो कर्मचारी Windows इस्तेमाल करना चाहते थे उन्हें उसे खुद install और manage करना आना चाहिए था, नहीं तो उन्हें hire नहीं किया जाता था
- अनुमान है कि 10 साल के भीतर जिन users को training की ज़रूरत होगी वे high-tech labor market से बाहर हो जाएँगे, या प्रतिस्पर्धी बने रहने के लिए घर पर खुद को प्रशिक्षित करेंगे
6. Action is Better Than Inaction: यह विश्वास कि कुछ करना, कुछ न करने से बेहतर है
- IT executives को “early adopters” और “pause and thinkers” में बाँटा जा सकता है, और लेखक के अनुसार सफल तथा सुरक्षित mission-critical systems बनाने वाले लोग दूसरे समूह के अधिक क़रीब होते हैं
- नई technology आते ही उसे तुरंत install करने के बजाय इंतज़ार करना, दूसरे शुरुआती adopters के परिणाम देखना, और अनुभवी लोगों के उभरने के बाद deploy करना अधिक सुरक्षित हो सकता है
- एक वरिष्ठ IT executive ने corporate wireless network अपनाने की योजना इस तरह बनाई: “2 साल इंतज़ार करो, फिर हमसे बड़ी company में wireless को सफलतापूर्वक deploy कर चुके किसी व्यक्ति को hire करो”
- इस बीच technology अधिक परिपक्व हो जाती है और उसकी कीमत भी बहुत नीचे आ जाती है
- इससे जुड़ा मुख्य उप-विचार यह है कि “अक्सर समझदारी भरा काम करने से आसान, मूर्खतापूर्ण काम न करना होता है”
- security outsourcing को भी 1~2 साल टालने और उन organizations की सिफ़ारिशें व राय सुनने की सलाह दी जाती है जो इस दौरान टिके रहे हों
- एक ऐसे customer के मामले में, जो बिना सत्यापन के बहुत पैसा खर्च करने वाला था, सलाह दी गई कि वह संबंधित conference LISA में अपने staff को भेजे ताकि वे वास्तविक उपयोग अनुभव वाले लोगों को खोज सकें
- वह staff member dinner पर product अनुभव रखने वालों को बुलाकर अनौपचारिक आकलन सुन सकता था
- IT manager ने बताया कि 200 डॉलर के dinner ने 400,000 डॉलर से अधिक के तकनीकी कष्ट को कम कर दिया
- पेशेवर “kung fu” का मतलब है कुछ न करके मूर्खतापूर्ण काम से बचना, और उस बचाव का श्रेय अपने bosses से दिलवाना
इसके अलावा कुछ छोटी मूर्खताएँ
- “हम target नहीं हैं”
- worms इतने बुद्धिमान नहीं होते कि यह तय कर सकें कि कोई website या home network दिलचस्प है या नहीं
- “अगर सब लोग किसी खास security फैशन वाले OS का इस्तेमाल करें, तो हम सुरक्षित हो जाएँगे”
- operating systems जटिल होते हैं, इसलिए उनमें security problems होती हैं, और system administration अब भी हल की हुई समस्या नहीं है
- फैशन के पीछे बदलने से administrators के लिए समय के साथ बनने वाली विशेषज्ञता हासिल करना और कठिन हो सकता है
- “अच्छी host security है, इसलिए firewall की ज़रूरत नहीं”
- यदि network fabric पर भरोसा नहीं किया जा सकता, तो network से होकर जाने वाला हर application संभावित target है
- उदाहरण के तौर on Domain Naming System का उल्लेख किया गया है
- “अच्छा firewall है, इसलिए host security की ज़रूरत नहीं”
- यदि firewall पीछे के hosts तक traffic को जाने देता है, तो उन systems की host security पर भी विचार करना होगा
- “अभी production में डालो, security बाद में देखेंगे”
- यदि अभी सही करने का समय नहीं है, तो यह पूछना चाहिए कि टूटने के बाद दोबारा करने का समय कहाँ से आएगा
- हो सकता है कि शुरुआत के कुछ दिन बचाने के लिए बाद में कई साल तक सुधार करते रहना पड़े
- “कभी-कभार होने वाली समस्याएँ रोकी नहीं जा सकतीं”
- इसका जवाब यह सवाल है: यदि aviation industry जान के मामलों में यही approach अपनाती, तो क्या आप commercial passenger aircraft में बैठते?
सुरक्षा पेशेवरों से अपेक्षित दृष्टिकोण
- लेखक का मानना है कि कंप्यूटर सुरक्षा “इस हफ़्ते की नई technology” में ज़रूरत से ज़्यादा डूबकर सामान्य समझ खो चुकी है
- security practitioners का काम प्रचलित मान्यताओं और वर्तमान स्थिति पर सवाल उठाना है, और ज़रूरत पड़ने पर सीधी चुनौती देना भी
- अंत में यह प्रश्न उठाया गया है कि यदि प्रचलित मान्यताएँ सचमुच प्रभावी होतीं, तो system compromises की दर कम होनी चाहिए थी
1 टिप्पणियां
Hacker News की रायें
लगता है फिर वही बात हो रही है: https://hn.algolia.com/?q=six+dumbest+ideas+in+computer+secu...
इस लेख में खंगालने लायक बहुत कुछ है, लेकिन मैं हमेशा Ranum के vulnerability research के प्रति विरोध के पीछे की सोच पर बात करना चाहता हूं। 90 के दशक के अंत से 2000 के शुरुआती दौर में Marcus Ranum और Bruce Schneier इस विचार के प्रमुख बुद्धिजीवी थे कि vulnerability disclosure से फायदे से ज्यादा नुकसान होता है, और यह काम बाहरी researchers के बजाय vendors को करना चाहिए। आखिरकार वह नजरिया सही नहीं निकला, और 2002 में बाहरी full-disclosure vulnerability research को “hacking” के दायरे में रखा जा सकता था, लेकिन आज बिल्कुल ऐसा नहीं है। security field के चार बड़े conferences तो छोड़िए, cryptography literature तक attack research को कवर करता है
पता नहीं छूट गया या नहीं, लेकिन passwords की बात न देखकर हैरानी हुई। minimum length को छोड़कर mandatory composition rules, periodic changes, और “password replacement” की कोशिशें मुझे मूल रूप से बेवकूफी लगती हैं। composition rules का नतीजा होता है कागज पर लिखना, वही password दोबारा इस्तेमाल करना, अंत में 1 जोड़ देना जैसी चीजें; और विकल्पों का UX भयानक या confusing होता है, और अंत में सब फिर password पर लौट आते हैं। बस मुझे अपनी चुनी हुई characters से X या उससे ज्यादा लंबा password बनाने दें, तो phone या computer न होने पर, या विदेश में होने पर भी मैं उसे सच में याद रख सकता हूं
suckmyDICK123!!जैसा कुछ डालता है। फिर भी आम तौर पर brute-force throughput कम होता है या 5 failures के बाद account lock हो जाता है, इसलिए आसानी से compromise नहीं होता। आजकल ज्यादातर लोग इतना जानते हैं कि “bots superhuman speed से passwords try करते हैं”, और कोई भी password policy खराब password choice को रोक नहीं सकती। यह वह case है जहां “responsible” लोग reality को solve करने में बहुत समय बरबाद करते हैं। bank जैसी sensitive एक-दो चीजों को छोड़कर, 1 मिनट खेले गए 80 games जैसे जबरन account मांगने वाले services में वही password इस्तेमाल करने का मन करता है। कई बार अलग GUI होने से paste भी नहीं हो पाता, और password manager इस्तेमाल कर सकते हैं, लेकिन ऐसा करने की कोई खास वजह नहीं होतीhacking cool हो सकती है। दूसरों के data और systems तक access करना नहीं, लेकिन अपने owned system को गहराई से समझकर उसे अपने फायदे के लिए malfunction कराने का तरीका ढूंढना cool है। पड़ोसी का lock pick करना खास नहीं, लेकिन अपना lock pick करना cool है; remote computer manipulate करके unauthorized access लेना खास नहीं, लेकिन अपने computer से वह काम करवाना जिसे करने से originally रोका गया था, cool है। possibilities के किनारे explore करने वाला attitude दुनिया को आगे बढ़ाता है, और शायद ही कोई successful human society रही हो जिसने box के अंदर ही रहने की तारीफ की हो
इस लेख में बहुत खराब judgment है। “मैंने अपना system सावधानी से design, implement और configure किया है, इसलिए test करने की जरूरत नहीं” जैसी बात security पर मैंने सुनी सबसे खराब views में से हो सकती है। “hacking social problem है, technical problem नहीं” कहना भी security through obscurity के करीब है, और यह हमेशा social problem भी नहीं होता। corporate espionage या nation-state actors को देखें तो ऐसा नहीं है
मुख्य समस्या आमतौर पर usability बनाम security का दुर्भाग्यपूर्ण समझौता होती है, और यहां जिन ज्यादातर बेवकूफाना ideas का जिक्र है, वे औसत user की असुविधा कम करने की कोशिश में security की बलि देने का नतीजा हैं। उदाहरण के लिए, default allow security के लिए सबसे खराब है और Windows की कई समस्याओं की वजह भी, लेकिन users को हर नए program के लिए साफ-साफ अनुमति देना पसंद नहीं होता। Microsoft ने जब confirmation dialog जोड़ा था, तब भी बहुत लोगों ने इसे software को बहुत ज्यादा झंझट वाला बना देने वाली खराब design माना। इसलिए “default allow”, “बुरी चीजों की सूची बनाना”, और “घुसपैठ के बाद patch करना” default बन गए। निजी तौर पर, मैं password को ही security के सबसे बेवकूफाना ideas में से एक मानता हूं। क्योंकि अच्छे password की परिभाषा ही है कि वह याद रखने में कठिन हो, proper keyboard न रखने वाले devices पर दर्ज करने में कठिन हो, और user के लिए लगभग हर लिहाज से असुविधाजनक हो। लेकिन कोई व्यावहारिक विकल्प भी नहीं है। Email links में अगर email access compromise हो जाए तो सब compromise हो जाता है, और password reset भी अक्सर वैसा ही है। Physical authentication devices में user घर से बाहर login नहीं कर पाता या उसे accessory हमेशा साथ रखनी पड़ती है, और लगभग हर तरीका अच्छी security habits मांगता है, जबकि 99.9% आबादी को इसमें खास दिलचस्पी नहीं होती
“कई exploits और उनका इस्तेमाल सीखना, ऐसे tools और techniques सीखने में समय लगाना है जो patch होते ही पुराने पड़ जाएंगे” — यह बात गलत है। असल में यह theory के साथ practical पहलू सीखना है, और बहुत उपयोगी है
इस list से “hacking is cool” हटाकर client trust डालूंगा। हाल में clients पर trust करने की कोशिशें बढ़ी हैं। जैसे mobile apps का यह proof मांगना कि operating system modify नहीं हुआ है, या Google का web में ऐसा ही DRM डालने की कोशिश करना। अगर network security model client software पर trust करने पर निर्भर है, तो वह पहले ही टूट चुका है
“default deny” के बारे में कहा गया है कि “यह default allow से बहुत ज्यादा कठिन नहीं है और आप रात में बेहतर सो सकते हैं”, लेकिन IT security प्रभारी तो बेहतर सोएगा, कंपनी के बाकी लोग बहुत चिढ़ेंगे क्योंकि कुछ भी करने के लिए IT department के साथ तीन-तीन बार आना-जाना पड़ेगा। और लोग जितना ज्यादा चिढ़ेंगे, उतनी ही संभावना है कि वे security concept को तोड़ने वाले workarounds अपनाएं। जैसे हर महीने password change जबरन कराने पर लोग
password1,password2,password3जैसी चीजें इस्तेमाल करते हैं। अच्छी IT security का मतलब सिर्फ network cable निकाल देना नहीं है; उसे user के लिए जादू की तरह अदृश्य और बाधा न डालने वाली होना चाहिएसुरक्षा-केंद्रित लेख आम तौर पर ऐसे लोग लिखते हैं जो सुरक्षा को अत्यधिक महत्व देते हैं, और अक्सर यह नज़रअंदाज़ कर देते हैं कि पूरी तरह सुरक्षा-केंद्रित approach सुरक्षित software के users के लिए कितनी मुश्किलें पैदा करती है। सुरक्षा को मैं हमेशा सुरक्षा और सुविधा के slider के रूप में देखता हूँ। पूरी तरह सुरक्षित design इतना असुविधाजनक होता है कि उसके users लगभग नहीं होते, और पूरी तरह सुविधाजनक design भी पर्याप्त सुरक्षित नहीं होता, इसलिए अंततः वही नतीजा हो सकता है। फिर भी यह लेख कुल मिलाकर पढ़ने लायक है, लेकिन इस विचार से मैं कड़ी असहमति रखता हूँ कि security expert का exploit लिखकर देखना या किसी खास system का दुरुपयोग करना सीखना बेवकूफी है। “सुरक्षित design” पढ़ने की तुलना में मैंने vulnerabilities और exploits का अध्ययन करके और उन्हें खुद white-hat तरीके से implement करके security कहीं ज़्यादा सीखी है। यह कुछ वैसा ही है जैसे “उसे जानना है तो उसके जैसा बनकर देखो”
यह ज़्यादातर 19 साल पुरानी बेहद खराब list है। “software और systems को design से ही सुरक्षित होना चाहिए था और failure handling को ध्यान में रखकर design किया जाना चाहिए था” कहने का मतलब है “अगर दुनिया perfect होती, तो सब कुछ शुरू से ही सुरक्षित होता।” ऐसा कभी नहीं होने वाला, इसलिए खोज के बाद patch वाली technique इस्तेमाल करनी पड़ती है, और जिन कंपनियों ने मिली हुई vulnerabilities को सच में patch किया है और गलतियों से भविष्य की coding practices सीखी हैं, उनके लिए यह अच्छा काम करती रही है। साथ ही अधिकांश systems static नहीं होते। ऐसा नहीं है कि आप एक बार सुरक्षित system release करते हैं और फिर कभी update नहीं करते; अधिकांश applications और systems अक्सर update होते हैं, और उसी दौरान नई vulnerabilities आ जाती हैं
scriptयाonclickजैसे keywords वाली requests block करके “fix” करना