इंटरनेट कनेक्शन काट दें
(computer.rip)- CrowdStrike जैसी बड़ी सुरक्षा घटनाओं के बाद “इसे इंटरनेट से कनेक्ट नहीं होना चाहिए था” जैसी प्रतिक्रिया आती है, लेकिन कई कामकाजी सिस्टमों में जानकारी का आदान-प्रदान ही मुख्य फ़ंक्शन होता है, इसलिए सिर्फ़ कनेक्शन काटने से समाधान नहीं होता
- एयरलाइन reservation और scheduling सिस्टम जैसे, संगठन और क्षेत्रीय सीमाओं के पार जाने वाले सिस्टम, फोन और telegraph की जगह लेने वाले communication infrastructure के ज्यादा करीब होते हैं; networking हटाने पर उनका असली value भी साथ में खत्म हो जाता है
- “इंटरनेट से कनेक्टेड नहीं” में एक standalone device, सख्त air gap, data diode, private WAN, VPN tunnel, सीमित routing, और AWS private VPC तक शामिल हो सकते हैं, इसलिए threat model बहुत बदल जाता है
- Offline या सीमित-कनेक्टिविटी environments में OS updates, package managers, internal repositories, TLS trust stores, cloud licenses, content updates, और Docker image handling तक—सब समय और लागत बढ़ा देते हैं
- ज्यादा सिस्टमों पर सीमित network policies लागू की जा सकती हैं और software को offline operations ध्यान में रखकर बनाया जा सकता है, लेकिन मौजूदा software ecosystem अब भी internet connection को default मानता है
“इंटरनेट से कनेक्ट मत करो” कहने की सीमाएं
- जब भी कोई बड़ी security incident खबर बनती है, “ऐसे systems इंटरनेट से जुड़े नहीं होने चाहिए” जैसी प्रतिक्रिया बार-बार आती है
- Security और reliability के लिहाज से यह फैसला सहज रूप से आकर्षक लगता है, लेकिन वास्तव में ऐसे operate होने वाले environments बहुत ज्यादा नहीं हैं
- मुख्य समस्या यह है कि सिर्फ़ “इंटरनेट से कनेक्ट नहीं करना” कहने भर से वास्तविक design, operational cost और threat model पर्याप्त रूप से specify नहीं होते
आधुनिक business systems communication devices के ज्यादा करीब हैं
- Abstract रूप से computer calculation के जरिए value बना सकता है, लेकिन industrial settings में systems का स्वरूप calculation से ज्यादा information technology वाला होता है
- Information technology को information input और output करनी होती है, और पुराने समय की तरह operator द्वारा tape डालने का तरीका real-time communication की तुलना में महंगा और धीमा है
- आधुनिक business computers ज्यादातर communication devices के रूप में काम करते हैं
- ऐसे systems कम हैं जो दूसरे business systems से जुड़े बिना value बनाते हों
- ऐसे connections अक्सर organizational boundaries और geographical boundaries के पार जाते हैं
- Airline reservation और scheduling systems की शुरुआत उन systems से हुई जो phone और telegraph की जगह लेते थे, और network उनके function में ही शामिल है
Maintenance और operations के लिए भी network चाहिए
- जिन systems में real-time communication business purpose के लिए अनिवार्य नहीं है, उनमें भी network connection operationally बहुत value रखता है
- Internet connection न हो तो software updates कैसे लाएंगे, system को कैसे monitor करेंगे—यहीं से रुकावट शुरू हो जाती है
- भले ही तय कर दिया जाए कि system “complete” है और updates या real-time monitoring की जरूरत नहीं, business requirements समय के साथ बदलती हैं
- Network connection ऐसे बदलावों को संभालने की cost काफी घटा देता है
“इंटरनेट से न जुड़ा” होने के कई स्तर हैं
- “इंटरनेट से कनेक्टेड नहीं” स्थिति का कोई एक मतलब नहीं है, बल्कि यह कई implementation तरीकों का समूह है
- संभावित रूप पूर्ण disconnect से लेकर सीमित connectivity तक फैले हुए हैं
- बिल्कुल कोई network connection न रखने वाला standalone device
- private LAN के अलावा कोई connection नहीं और security boundary के पार data न जाने वाला सख्त air gap
- DVD-R के जरिए data को security boundary के अंदर लाने वाला air gap
- cross-domain solution या data diode से low-security network से high-security network में data move करने वाली संरचना
- NSA certification के बिना cross-domain solution इस्तेमाल करने वाली संरचना
- Private wide-area networks भी कई levels में बंटते हैं
- पूरी तरह independent physical infrastructure और tamper-prevention measures वाला private WAN
- shared ducts, leased dark fiber, lit fiber की wavelength इस्तेमाल करने वाला रूप
- MPLS-based virtual private ethernet
- encryption और authentication वाला tunneling-based virtual private ethernet
- Public communication networks के ऊपर private traffic को भी कभी-कभी “disconnected” कहा जाता है
- internet जैसे common-carrier network के ऊपर hardware devices द्वारा encryption/authentication tunnel बनाने वाला रूप
- NSA certification के बिना devices इस्तेमाल करने वाला रूप
- operating system network stack को low level पर configure करके tunnel bypass रोकने वाला verified software tunnel
- कम verification level वाला software tunnel
- WireGuard और iptables scripts को combine करने वाला रूप
- Limited internet connection भी इसी शब्द में शामिल कर दिया जाता है
- policy-based routing आदि से बेहद narrow traffic flows ही allow करने वाला private network
- ऐसी structure जिसमें allowed flows पुराने Jira tickets में बचे हुए हैं और कुछ “चलाने के लिए” जोड़े गए हैं
- firewall-based structure जिसमें outbound relatively permissive और inbound strict है
- Cloud environments में भी scope बदलता रहता है
- बाहरी routing के बिना AWS private VPC
- PrivateLink आदि के जरिए दूसरे private VPC से communicate करने वाला VPC
- ऐसी structure जिसमें जुड़े हुए कुछ VPC internet से routed हैं
- NAT Gateway और Internet Gateway होने के बावजूद security groups को दोनों directions में strict configure करने वाली structure
- इन सभी रूपों को “इंटरनेट से connected नहीं” कहा गया है, लेकिन attack surface और risk हर मामले में अलग है
- Airline reservation system को “इंटरनेट से कनेक्ट मत करो” कहते समय अगर मतलब पूरी तरह network-less स्थिति नहीं है, तो वास्तव में यह बीच के किसी level की बात है, और हर level के practical considerations अलग होते हैं
Offline environments लागत और schedule को बहुत बढ़ा देते हैं
- Internet connection न होने या strongly restricted network में software operate करने से schedule और cost estimates काफी बढ़ जाते हैं
- AWS private VPC जैसे weak रूप के लिए roughly 3–5 गुना मान सकते हैं
- complete disconnect के करीब strong रूपों में यह 10 गुना से भी बहुत ज्यादा हो सकता है
- लगभग पूरा software ecosystem internet connection को आधार मानकर design किया गया है
- Operating systems online servers से updates लाने की कोशिश करते हैं
- Paid OS vendors private network के अंदर update infrastructure को अलग paid license के रूप में दे सकते हैं
- Free OS में आप खुद समाधान कर सकते हैं, लेकिन latest technology इस्तेमाल करने पर बड़ी परेशानी हो सकती है
- Development और deployment process में कई package managers और internal repositories से जुड़ी समस्याएं बार-बार आती हैं
- हर package manager में private internal repository support का level अलग होता है
- कई package managers, calling methods और runtime environments के combination से complexity बढ़ती है
- Internal services के TLS certificates भी repetitive work बनाते हैं
- Private network के अंदर services अक्सर popular CA के root program में शामिल certificates का इस्तेमाल नहीं करतीं
- JRE जैसे components का अलग trust store होता है, और कुछ technology stacks में behavior libraries के हिसाब से बदलता है
- Operating system trust store होने के बावजूद अगर हर tool अपना store इस्तेमाल करे, तो अलग adjustment जरूरी होता है
- Cloud license और entitlement checks भी बाधा बनते हैं
- कुछ software cloud license check के लिए बाहर connect करने की कोशिश करते हैं
- Workarounds बड़े पैमाने पर firewall exceptions जोड़ने से लेकर custom license scheme issue करने तक हो सकते हैं, और समय लेते हैं
- Offline content updates सिर्फ vendor process की वजह से भी complex हो सकते हैं
- एक enterprise software case में पुराने customer support portal और अलग entitlement portal से गुजरना पड़ा
- Account creation और escalation में 3 महीने से ज्यादा लगे, और final portal में invalid TLS certificate था
- Documented update application procedure अब काम नहीं करती थी, इसलिए engineer के साथ लंबे email exchange की जरूरत पड़ी
- 1-year license के लिए five-figure amount चुकाया गया, लेकिन इस्तेमाल के लिए तैयार होते-होते वह लगभग expire हो गया, और extension license जारी करने में delay से CI pipeline रुक गई
- Offline operations की difficulty इसलिए नहीं होती कि कोई एक individual task impossible है, बल्कि इसलिए कि हर task थोड़ा-थोड़ा कठिन हो जाता है—यह death by a thousand cuts जैसा है
- Offline environment को ध्यान में न रखने वाले products अक्सर temporary scripts और patchwork से respond करते हैं, और उसका technical debt offline environment operate करने वाले customers पर चला जाता है
- Red Hat इस क्षेत्र में relatively अच्छा handle करता है, लेकिन जितना time बचता है उतनी cost cash में देनी पड़ती है
ऐसे environments दुर्लभ हैं और कुछ industries में केंद्रित हैं
- Non-internet-connected environments के strong रूप मुख्य रूप से defense और intelligence agencies में दिखते हैं
- कुछ banks में भी strong network segregation practices होती हैं
- Defense, intelligence agencies और banks high-cost और long-cycle industries के रूप में भी जाने जाते हैं, और इसका ऐसी operating styles से संबंध है
- Restricted-connectivity environments के weak रूप मुख्य रूप से finance और healthcare जैसी heavily regulated industries में ज्यादा हैं
- Security को बहुत महत्व देकर network को strongly lock down करने वाली सामान्य software companies भी कभी-कभी होती हैं
अभी किए जा सकने वाले practical responses
- कम systems का internet से connected होना अपने आप में बुरा विचार नहीं है
- लेकिन current software industry internet न होने या restricted environments में आसानी से operate करने के लिए तैयार नहीं है
- Practical response पूर्ण disconnect की मांग करने से ज्यादा, limited connectivity और offline readiness बढ़ाने के करीब है
-
Network policies को जितना संभव हो restrict करना
- जितने ज्यादा systems संभव हों, उन पर restricted network policies लागू करनी चाहिए
- Cloud providers अब पहले की तुलना में ऐसे configurations बनाना आसान कर रहे हैं
- AWS में practical non-internet routing environment operate करना बहुत आसान नहीं है, लेकिन impossible जितना difficult भी नहीं है
- AWS managed service scope के अंदर रहें तो आम तौर पर pain कम होता है, लेकिन cost आती है
-
Offline environments को ध्यान में रखकर software बनाना
- जिन features को बाहर connect करना पड़ता है, उन्हें संभव हो तो disable किया जा सकना चाहिए
- Disable करना मुश्किल हो तो customer को इस्तेमाल होने वाला endpoint बदलने की अनुमति होनी चाहिए
- अगर endpoint बदलने की सुविधा देते हैं, तो customer को अपना endpoint operate करने का तरीका भी चाहिए
- अगर यह simple static files हैं, तो nginx और एक directory से आसानी से provide किया जा सकता है
- अगर API है, तो internal implementation customer को deploy करनी पड़ सकती है और maintenance burden पैदा होता है
-
TLS और dependency assumptions कम करना
- Offline environments में दूसरी services से connect करने जैसी छोटी assumptions भी complex हो जाती हैं
- यह assume नहीं करना चाहिए कि Let’s Encrypt से connect किया जा सकता है
- Offline environments में लगभग हमेशा internal certificate authority शामिल होती है
- system trust store का इस्तेमाल करना चाहिए
- Deployment time पर requirements या dependencies fetch नहीं करनी चाहिए
- Docker का लाभ packages को self-contained बनाना था, लेकिन कुछ containers npm repository आदि तक access न होने पर start ही नहीं होते
- हर Docker container में TLS trust store modify करना पड़ सकता है, इसलिए offline environment में Docker उल्टा management को और difficult बना सकता है
CrowdStrike incident और internet connection का संबंध
- CrowdStrike incident पर “यह internet से connected क्यों था” जैसी प्रतिक्रिया कई बार आई, लेकिन internet connection होना या न होना उस समय हुई problem से लगभग orthogonal था
- CrowdStrike content update ऐसी update है जिसे ideal environment में offline environment तक भी quickly provide किया जाना चाहिए
- वास्तविक strong offline environments में internal CrowdStrike update mirror कई दिन, कई हफ्ते, कई महीने या कई साल पीछे हो सकता है
- ऐसा delay problem से बचा सकता है, लेकिन यह दो गलतियों के overlap से संयोगवश सही बैठ जाने जैसी स्थिति के करीब है
1 टिप्पणियां
Hacker News की राय
मैं security/systems/operations में काम करता हूँ, लेकिन इस आधारभूत धारणा से मूल रूप से सहमत नहीं हूँ। लेखक जब कहते हैं कि “यह इतना आसान नहीं है”, तो मैं समझता हूँ और पूरी तरह सहमत हूँ, लेकिन इसका मतलब यह नहीं कि काम अच्छी तरह हो रहा है
अफसोस की बात है कि ज़्यादातर लोग यह काम अच्छी तरह नहीं करते, और पूरी industry ऐसी बनी है कि खराब काम करते हुए भी टिके रहना संभव हो, जबकि अच्छा काम करना मुश्किल हो
अगर आप digital signage deploy कर रहे हैं, तो network access को सिर्फ मेरे server IP addresses तक allowlist किया जाना चाहिए, और केवल signed updates व certificate pinning से बने connections ही स्वीकार होने चाहिए
ऐसा करने पर remote attacker के लिए छेड़छाड़ करना लगभग असंभव हो जाता है। Internet of Things (IoT) के फैलाव से बढ़ी security industry को देखें, तो निश्चित रूप से ऐसे signage या दूसरे IoT/SCADA/deployment devices मौजूद हैं जिनमें खुले ports और default passwords बचे हुए हैं
IoT बस computers ही हैं, लेकिन वे ऐसे computers भी हैं जिन्हें उन servers या virtual machines से भी ज़्यादा छोड़ दिया जाता है जिन्हें हम पहले से ठीक से operate नहीं कर पाते
कुछ जगहें अच्छा करती हैं, लेकिन वे बेहद कम हैं, क्योंकि अच्छा करने के लिए reward structure नहीं है। “best practices” या vendor guidelines का पालन करना अच्छे काम का संकेत नहीं, बल्कि अक्सर सिर्फ इतना होता है कि आपने उतना किया है जितना vendor support कर सके; और कई मामलों में इसका मतलब unrestricted network access होता है
आपको अब भी network bugs, cryptographic vulnerabilities, configuration mistakes और ऐसे दूसरे issues की चिंता करनी होगी जिनसे remote attacker system का दुरुपयोग कर सकता है। यह तर्क देने के लिए आपको केवल ज़्यादा lock-down किया गया उदाहरण नहीं, बल्कि सचमुच Internet से न जुड़ा उदाहरण देना होगा
मुझे समझ नहीं आ रहा कि blog लेखक से आपकी असहमति कहाँ है। या आपका मतलब यह है कि क्योंकि लोगों में ऐसी क्षमता नहीं है, इसलिए Internet-connected systems की security सुधारना मूल रूप से असंभव है?
Sweden में Internet से अलग एक private network Sjunet है, जिसका उपयोग healthcare providers करते हैं। उद्देश्य computers को उपयोगी communication devices बनाना है, लेकिन hospital IT को पूरे Internet के सामने expose नहीं करना
Sjunet members से अपेक्षा की जाती है कि वे अपने network को जानते हों और IT को सख्ती से control करते हों
Sjunet को industry-level air-gapped environment के रूप में भी देखा जा सकता है। मेरा मानना है कि यह security सुधारता है, और हर organization के अपने विशाल allowlist वाले air-gapped network चलाने की तुलना में लागत भी कम है
यह झूठी निश्चिंतता देता है और खराब security policies का बहाना भी बनता है। bandwidth कम और महंगी है
यह एक network है जो county offices, city halls जैसी institutions को जोड़ता है, ताकि वे नागरिकों की personal information stored central databases तक access कर सकें। इसका उपयोग address change, नया ID card जारी करने, birth और marriage registration जैसे कामों के लिए होता है
जहाँ तक मुझे पता है, “Źródło” app एक अलग “air-gapped” computer पर चलता है, जिसमें Internet नहीं होता लेकिन internal network access होता है, और smartcard के जरिए cryptographic client certificate से authenticate करता है
क्या सभी पर latest patches लगे हैं? क्या उन्हें पता है कि लोग कोई भी USB device नहीं लगाते?
Tor जैसा, लेकिन suspicious चीज़ों के बिना, ऐसा कुछ अच्छा होगा
कंट्रोल इंजीनियर के तौर पर सैकड़ों मशीनें बनाई हैं। फील्डबस नेटवर्क के लिए Ethernet केबल होते हैं, लेकिन उन्हें कभी भी इंटरनेट से कनेक्ट नहीं होना चाहिए
मोहल्ले के इंडस्ट्रियल पार्क में हर टूल और मोल्ड वर्कशॉप में Ethernet पोर्ट वाली CNC मशीनें हैं जिन्हें इंटरनेट पर नहीं डालना चाहिए। कस्टम उपकरण, conveyor lines, presses, robots, CNC, pump stations वगैरह वाले हर manufacturing plant में Ethernet इस्तेमाल होता है, लेकिन वे PLC और HMI सिस्टम इस्तेमाल करते हैं जो इंटरनेट exposure के लिए उपयुक्त नहीं हैं
लेख कहता है कि आधुनिक work computers लगभग मुख्य रूप से communication devices हैं, और दूसरे business systems से जुड़े बिना value बनाने वाले practical systems बहुत कम हैं, लेकिन यह पूरी manufacturing industry और उस manufacturing से बने electronic devices को नज़रअंदाज़ कर रहा है
लाखों embedded systems और PLC हर 1 millisecond में जांचते हैं कि physical/logical digital inputs की state बदली है या नहीं, और अगर बदली है तो physical/logical digital outputs की state बदलते हुए पूरे दिन value बनाते हैं
जिस resistance welder की casting 100 साल से भी पहले बनी थी, और जिसका आखिरी update 2003 में recipe setting के लिए PLC और monochrome screen लगाने का था, उसमें 2024 वाला security system डालने की जरूरत नहीं है। clipboard लेकर जाइए, target values डालिए और steel को ठीक से melt कर दीजिए
आम तौर पर ऐसी मशीन से connect करने के लिए laptop और Ethernet patch cable लेकर मशीन के सामने तक जाना पड़ता है। अगर इससे ज्यादा चाहिए, तो ग्राहक से उम्मीद होती है कि वह इसे firewall वाले operational technology (OT) network में रखे, या Tosibox, Ixon जैसे SCADA/VPN उपकरणों से information technology (IT) और OT के बीच connection बनाए
आप जिस चीज़ से काम कर रहे हैं, वह शायद ऐसी चीज़ न हो जिसे कोई exploit करना चाहे, लेकिन PLC critical infrastructure और advanced manufacturing facilities में अक्सर मिलते हैं, इसलिए malicious actors के लिए आकर्षक target हैं। वे critical infrastructure को exploit करने की कोशिश कर सकते हैं, या किसी ऐसे कमजोर security वाले device को infect करना चाह सकते हैं जिससे किसी दिन engineering laptop जैसे high-value endpoint सीधे connect कर सके
https://www.cisa.gov/news-events/cybersecurity-advisories/aa... - Water Infra
https://claroty.com/team82/research/evil-plc-attack-using-a-...
यह तर्क अब भी समझ नहीं आता कि क्योंकि internet-centric development practices का इस्तेमाल नहीं कर पाएंगे, इसलिए systems को air-gap नहीं करना चाहिए। मुझे यह दावा बेतुका लगता है
अगर किसी system का Ethernet port epoxy से बंद करना पड़ता है, तो उसे शुरू से ही internet-centric development practices से program नहीं किया जाना चाहिए था। MRI machine boot होते समय NPM से JS dependencies खींचती है? सीधे जेल। रूपक नहीं, सचमुच
McDonald’s kiosk से छेड़छाड़ करते हुए किसी का video देखने के बाद, मैंने अलग-अलग जगह दिखने वाले equipment पर वही चीज़ आज़मानी शुरू की
एक food court में Windows चलाने वाला और internet तक पूरा access रखने वाला kiosk था। कोई malware download करके credit card data चुरा सकता था। हर बार इस्तेमाल पर मैंने उसे power off किया या screen पर message छोड़ दिया, और आखिरकार उन्होंने उसे kiosk mode में चलाना शुरू कर दिया
दूसरा parking kiosk था, जो बिल्कुल harden नहीं किया गया था। लगता है criminals ने अभी notice नहीं किया है
तीसरा beer brand का interactive display था। उससे कोई बड़ा नुकसान होने वाला नहीं था, लेकिन Notepad खोलकर “Drink water” छोड़ देना अच्छा लगा। आखिरकार उन्होंने उसे बंद कर दिया, और वह भी एक solution है
“random passers-by को पैसे न दें” requirements list में काफी ऊपर होना चाहिए था, लेकिन reality में ऐसा नहीं था
इस हिस्से से सच में सहमत हूं। मैं IntelliJ के JRE trust store को यह समझाने की कोशिश कर रहा था कि उसे zscaler के लिए नया certificate इस्तेमाल करना है; selectable JDK दो-तीन थे, और मैंने हर एक के trust store में नया certificate डाल दिया, फिर भी यह काम नहीं कर रहा था और समझ नहीं आया क्यों
hamnet भी है। 44Net IP block पर कुछ हिस्सों की internet routing हो सकती है और कुछ की नहीं
https://hamnetdb.net/map.cgi
amateur radio frequency bands इस्तेमाल करने की वजह से इस पर दिलचस्प constraints हैं। commercial use पूरी तरह प्रतिबंधित है
यह उस frequency band का social contract है, इसलिए 136kHz से 241GHz तक कई bands तक सस्ती पहुंच मिल जाती है, लेकिन आप पैसे नहीं कमा सकते
यह केवल Netherlands और Germany में काफी फैला हुआ है: https://hamnetdb.net/map.cgi . यहां Spain में मेरे आसपास कहीं भी उपलब्ध नहीं है
airline reservation system को कम-से-कम network से जुड़ा होना चाहिए, यह काफी साफ लगता है, और मैंने बहुत कम लोगों को यह कहते सुना है कि सब कुछ offline होना चाहिए। लेकिन उदाहरण के लिए, मैंने सुना कि workshop की lathe machine इस घटना से रुक गई थी
क्या उसे सचमुच online होना चाहिए था, इस पर सोचना पड़ेगा। बेशक कोई वजह होगी, लेकिन उस वजह को risk के मुकाबले तौलना चाहिए
इसके अलावा fridge, kettle, garage door जैसे internet से जुड़े और भी ज्यादा हास्यास्पद उदाहरण हैं। पता नहीं ये CrowdStrike incident से प्रभावित हुए थे या नहीं, लेकिन अगर नहीं भी हुए, तो अगली बार बस समय की बात है
connected न होने वाले system को “बहुत, बहुत झुंझलाहट भरा” कहने वाली बात पर, एक user के तौर पर मेरा अनुभव है कि सारी security “बहुत, बहुत झुंझलाहट भरी” होती है। two-factor authentication, mandatory password changes, locked devices, malware scanners, link sanitizers—इनमें से कुछ जरूरी हैं और कुछ बकवास हो सकते हैं, लेकिन कौन क्या है यह तय करने की मेरी पात्रता नहीं है, और इतना तय है कि ये सब friction पैदा करते हैं
मेरा बड़ा निष्कर्ष यह नहीं है कि “इन सभी systems को internet से connect नहीं होना चाहिए”, बल्कि कुछ और बातें हैं
पहला, ऐसे systems को outbound network flow allow नहीं करना चाहिए। इससे सभी automatic updates रुक जाएँगे, और बाद में उन्हें internal deployment channel से manage किया जा सकेगा
दूसरा, ऐसा न भी करें तो भी कई enterprise software products में automatic updates बंद किए जा सकते हैं। Windows इसका प्रमुख उदाहरण है, और CrowdStrike खुद भी ऐसा ही है। सुना है कि CS customers में कुछ ने automatic updates बंद करके manual deployment किया और नुकसान से बच गए
तीसरा, point 2 के साथ, updates को थोड़ा smoke test करने के बाद gradual rollout करना चाहिए। एहतियात के तौर पर। यह भी सुना है कि CS customers में कुछ ने gradual rollout करके असर को सिर्फ कुछ devices तक सीमित रखा
यह लेख उस दौर का काफी अच्छा सार देता है जब हम military customers को cutting-edge AI solutions deliver करते थे। 80% effort internet-assuming tools को air-gapped environment में smoothly चलाने में लगता था