साइबरसिक्योरिटी अब Proof of Work की तरह काम करती है

 (dbreunig.com)
6 पॉइंट द्वारा GN⁺ 2026-04-16 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Anthropic का LLM ‘Mythos’ जटिल नेटवर्क attack simulation में इंसानों से ज़्यादा तेज़ और सटीक प्रदर्शन करता है, और इसकी access केवल सीमित core developers को दी गई है
  • AI Security Institute के test में Mythos ने 32-स्टेप enterprise network attack simulation को 10 में से 3 बार पूरी तरह सफलतापूर्वक पूरा किया, और token budget बढ़ने पर इसका प्रदर्शन बेहतर हुआ
  • यह नतीजा दिखाता है कि security अब ऐसी संरचना में बदल रही है जिसमें attackers से ज़्यादा tokens लगाकर ही defense किया जा सकता है, यानी Proof-of-Work जैसी प्रतिस्पर्धा
  • LiteLLM·Axios supply chain attack के बाद, open source dependencies को LLM से replace करने या tokens लगाकर security मज़बूत करने की कोशिशें फैल रही हैं
  • security में अब तकनीकी creativity से ज़्यादा resource investment की मात्रा निर्णायक कारक बन रही है, और इससे development process में ‘hardening’ स्टेप जोड़ने का रुझान बन रहा है

सुरक्षा की वह संरचना जो ‘Proof of Work’ की तरह काम करती है

  • Anthropic का LLM ‘Mythos’ कंप्यूटर security tasks में शानदार प्रदर्शन दिखा रहा है, इसलिए इसे सार्वजनिक रूप से जारी किए बिना केवल मुख्य software creators तक access दिया गया है
    • Mythos जटिल नेटवर्क attack simulation को इंसानों की तुलना में कहीं अधिक तेज़ी से पूरा करता है
    • AI Security Institute(AISI) के मूल्यांकन में भी इसने पिछले models की तुलना में एक स्तर ऊँची cyber attack execution capability साबित की
  • ‘The Last Ones’ नामक 32-स्टेप enterprise network attack simulation में Mythos ने 10 में से 3 बार पूरी सफलता हासिल की
    • AISI ने हर प्रयास में 100 million tokens (लगभग 12,500 डॉलर) का उपयोग किया
    • test किए गए models में केवल Mythos ने पूरा attack पूरा किया, और token budget बढ़ने पर इसका प्रदर्शन लगातार बेहतर होता गया
    विज्ञापन
  • यह परिणाम security economics को एक सरल सूत्र तक ले आता है: “defense के लिए attacker द्वारा इस्तेमाल किए गए tokens से ज़्यादा tokens खर्च करने होंगे”
    • security strengthening का निर्धारण creativity से अधिक resource investment से होता है
    • यह cryptocurrency के Proof of Work mechanism जैसी संरचना है, जहाँ ज़्यादा computing resources लगाने वाला पक्ष जीतता है

नई security economy के संकेत

  • open source software का बढ़ता महत्व

    • हाल के LiteLLM और Axios supply chain attacks के बाद, कुछ लोगों ने dependency code को AI agents से फिर से implement करने का प्रस्ताव रखा है
    • Andrej Karpathy ने कहा कि “dependencies का फिर से मूल्यांकन होना चाहिए, और साधारण functions को सीधे LLM से implement करना बेहतर है”
    • अगर security token investment के अनुपात में बढ़ती है, तो कंपनियाँ open source libraries में tokens लगाकर security को मज़बूत करेंगी तो उनके अधिक सुरक्षित होने की संभावना है
    • लेकिन व्यापक रूप से इस्तेमाल होने वाले OSS का attack value भी अधिक होता है, इसलिए attackers के पास भी अधिक resources लगाने की incentive मौजूद रहती है

  • development process में ‘Hardening’ स्टेप जोड़ना

    • अभी developers आम तौर पर development → code review की 2-स्टेप process का पालन करते हैं, और हर स्टेप में अलग models का इस्तेमाल करते हैं
    • Anthropic code review के लिए समर्पित service(Code Review) देता है, जिसकी कीमत हर review पर लगभग 15~20 डॉलर है
    • आगे चलकर development → review → hardening का 3-स्टेप cycle आम हो सकता है
      1. विकास: feature implementation और user feedback के आधार पर iteration
      2. रिव्यू: documentation, refactoring, quality improvement
      3. Hardening: बजट की सीमा के भीतर automated vulnerability discovery चलाना
      विज्ञापन
    • पहले स्टेप में human time सीमित कारक है, जबकि आख़िरी स्टेप में cost सीमित कारक बनती है

लागत संरचना और security की सीमाएँ

  • code लिखना अपने आप में अब भी सस्ता है, लेकिन security सुनिश्चित करने के लिए attacker से ज़्यादा tokens खरीदने पड़ेंगे
  • भले ही models की inference efficiency बेहतर हो, security strengthening की लागत attack value से तय होती है, इसलिए पूरी तरह लागत घटाना मुश्किल है
  • नतीजतन, security तकनीकी creativity की बजाय market-based resource competition में बदलती दिख रही है

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2026-04-16
Hacker News टिप्पणियाँ

  • कोडबेस तक पहुँच ही असली कुंजी है। अभी का LLM-आधारित security scanning मूलतः साधारण bash script के स्तर का है, जो हर file को घुमाकर “vulnerability ढूँढो” जैसा prompt फेंकता है
    लेकिन अगर defender पूरे source को नियंत्रित करता है, तो वह इससे कहीं अधिक कुशलता से काम कर सकता है। उदाहरण के लिए PR-स्तर पर केवल बदली हुई files को scan किया जा सकता है, या security-संबंधित code पर अधिक tokens लगाए जा सकते हैं। Attacker को हर बार नया scan करना पड़ता है, जबकि defender एक ही scan में सभी संभावित vulnerabilities पहले से खोज सकता है
    आखिरकार cost asymmetry मौजूद है, और efficiency के मामले में defender को बढ़त मिलती है। Attacker को कई चरणों वाली exploit chain पूरी करनी पड़ती है, जबकि defender को उनमें से बस सबसे कमजोर कड़ी एक ही रोकनी होती है

    • Attacker बहुत हैं और defender एक है, ऐसे में यह कहना कि economies of scale defender के पक्ष में है, सहज नहीं लगता। यह मान लेना कि code access संभव नहीं होगा, security के लिहाज़ से अच्छा नहीं है। हर security review source access को आधार मानता है
    • फिर भी यह तरीका software development की लागत बढ़ाता है। “हमको ही कौन target करेगा” जैसी ढीली सोच अब नहीं चलेगी
    • हाल की podcast Security Cryptography Whatever में जैसा कहा गया, यह दिलचस्प था कि अभी harness सुधारने से ज़्यादा असरदार रणनीति “अगले model का इंतज़ार करना” है
    • समस्या यह है कि ऐसा approach “किसी एक developer के PC के संक्रमित होने वाली supply-chain attack” जैसी घटना को बढ़ाकर “पूरे source code leak और automated audit” के स्तर तक ले जा सकता है। ऐसी दुनिया startups के लिए किसी dark forest जैसी लगेगी
    • Defender को हर हिस्से को मज़बूत करना पड़ता है, लेकिन attacker को सिर्फ एक vulnerability चाहिए

  • लेख में उल्लिखित AI Security Institute(AISI) दिलचस्प लगा, तो मैंने उसे देखा। यह मुख्यतः DeepMind या OpenAI पृष्ठभूमि वाले लोगों का संगठन निकला। security industry के लोग लगभग नहीं हैं। इसलिए “system को harden करने के लिए ज़्यादा tokens खर्च करने होंगे” वाला निष्कर्ष कुछ हद तक AI industry-केंद्रित तर्क जैसा सुनाई देता है। यह भी सवाल है कि formal verification जैसे विकल्पों का ज़िक्र क्यों नहीं हुआ। यह भी लगता है कि NVIDIA ऐसी दलील का GPU बिक्री में उपयोग कर सकता है

    • सोच रहा हूँ कि इसके उलट रुख लेने वाले प्रसिद्ध security researcher कौन हो सकते हैं। वास्तव में कई researchers इस दावे से सहमत दिखते हैं। अभी बहस का केंद्र यह है कि LLM fuzzing-स्तर का innovation है या उससे भी बड़ा
    • संदर्भ के लिए, AISI UK government के अधीन एक संस्था है और Department for Science, Innovation and Technology (DSIT) के अंतर्गत आती है। हालांकि graph को साधारण linear रूप में खींचना जैसी analysis पद्धति कुछ कमज़ोर लगी

  • Tony Hoare की यह बात प्रभावशाली लगी: “software design के दो ही तरीके हैं। या तो इतना simple बनाओ कि उसमें दोष न हों, या इतना complex कि दोष दिखें ही नहीं”

    • पूरी तरह simple बना देने से हर attack नहीं रुकता, लेकिन attack surface कम करने का प्रभाव बड़ा होता है। उदाहरण के लिए अगर system को इस तरह design किया जाए कि network message को process करने से पहले signature verification अनिवार्य हो, तो unsigned messages स्वीकार करना कठिन हो जाता है। आज के कई systems का threat model आवश्यकता से अधिक व्यापक है
    • लेकिन “complexity” का पैमाना इंसान और LLM के लिए अलग है। जो इंसान को जटिल लगे, वह LLM को सरल लग सकता है। इसलिए यह approach कितना असरदार रहेगा, इस पर संदेह है

  • Security हमेशा से सामने वाला कितना पैसा खर्च कर सकता है, इसी खेल का हिस्सा रही है। LLM आने से सिद्धांत नहीं बदला। Karpathy की “dependencies से बेहतर copy” वाली philosophy भी पहले से Go language के कहावत-स्तर के विचार में मौजूद है। “security obscurity से नहीं मिलती” वाला सिद्धांत भी पुराना है

    • लेकिन obscurity पूरी तरह बेकार भी नहीं है। यह defense की कई layers में से एक सहायक layer हो सकती है। आदर्श यह है कि system को पूरी transparency मानकर harden किया जाए, फिर उसके ऊपर थोड़ी opacity जोड़ी जाए
    • “Defend करने के लिए attacker से ज़्यादा tokens खर्च करने होंगे” यह नई बात नहीं है। physical security में भी यही सच था। आखिरकार AI युग में भी AI से AI को defend करना होगा। शुरुआत developers द्वारा इस्तेमाल किए जा रहे code-generation models के prompts की जाँच से करनी चाहिए

  • मैं लेख की बातों से मोटे तौर पर सहमत हूँ। “अंक चालाकी से नहीं मिलते” जैसी पंक्ति थोड़ी खतरनाक लगती है। Cybersecurity का मूल अभी भी human systems में है। GPU time पर बहुत खर्च करना ज़रूरी हो सकता है, लेकिन अंततः संगठन की security culture और discipline ही जीत-हार तय करते हैं। nuclear या aviation industry जैसी, ऐसी discipline चाहिए जो आम तौर पर बड़े हादसों के बाद ही बनती है।
    इसी संदर्भ में 1 साल पहले का यह लेख आज की स्थिति को लगभग भविष्यवाणी की तरह समझाता है

  • “System को harden करने के लिए attacker से ज़्यादा tokens खर्च करने होंगे” इस दावे पर, मुझे Ticketmaster API automation के लिए खुद script लिखने का पुराना अनुभव है। उन्होंने PerimeterX से defense मजबूत किया था, लेकिन मैंने 3 दिन में उसे bypass कर लिया। हाल में मैंने ChatGPT के Cloudflare Turnstile को bypass करने का तरीका भी लगभग इसी तरह बनाया
    यह ऐसे उदाहरण थे जो दिखाते हैं कि करोड़ों डॉलर खर्च कर बनाए गए security products भी व्यवहार में निरर्थक साबित हो सकते हैं
    संबंधित HN पोस्ट

  • LLM द्वारा खोजी गई security incidents सच में नई vulnerabilities हैं, या वे मौजूदा security knowledge का ही विस्तार हैं — यह जानने की उत्सुकता है। अगर दूसरी बात सही है, तो फिर हम उन्हें खुद व्यवस्थित रूप से क्यों नहीं ढूँढ पाते, यह सवाल उठता है

  • यह research Proof of Work जैसी इसलिए लगती है क्योंकि AISI ने कहा कि “जितने ज़्यादा tokens खर्च करो, performance उतनी बढ़ती जाती है।” यानी यह मान लिया गया कि attack success rate token consumption के अनुपात में बढ़ता है। लेकिन experiment 32-step network intrusion scenario था, और उसे पूरा करने वाला model सिर्फ Mythos था। साधारण code libraries में diminishing returns का बिंदु बहुत जल्दी आ सकता है
    Open source projects में defender और attacker दोनों की token consumption बढ़ेगी, इसलिए संभव है कि यह सीमा और जल्दी आ जाए

    • Mythos हर प्रयास में सफल नहीं हुआ था, और experimental network में वास्तविक defense systems भी मौजूद नहीं थे। फिर भी AI को कम करके देखने की वजह नहीं है। 3 महीने बाद के models बिल्कुल दूसरे स्तर पर होंगे
    • मुझे cybersecurity की गहरी जानकारी नहीं है, लेकिन 32 steps से 33 steps पर जाने में token cost की growth rate ही शायद मुख्य बात है। अगर defense चरण-दर-चरण independent है, तो attack success probability p^N की तरह तेज़ी से गिरती है

  • आखिरकार सवाल यह है — इंसानों द्वारा लिखे गए codebase को सुरक्षित रखना सस्ता है, या agents की फौज द्वारा generate किए गए code को सुरक्षित रखना

  • अभी की तरह model को पूरे codebase पर अंधाधुंध फेंकना अक्षम है। मेरे प्रयोग में, अगर model को source-to-sink trace को संरचनात्मक ढंग से explore करने के लिए ट्यून किया जाए, तो लागत काफ़ी घट जाती है।
    अब हम उस दौर में पहुँच गए हैं जहाँ systems पूरे code के context को visualize कर सकते हैं और fracture points को सटीक पकड़ सकते हैं। यह software quality सुधारने में एक बड़ा turning point हो सकता है