Microsoft पर सुरक्षा से ज़्यादा मुनाफ़े को प्राथमिकता देने का आरोप, व्हिसलब्लोअर का दावा
(propublica.org)- Microsoft के पूर्व कर्मचारी Andrew Harris का दावा है कि 2016 में AD FS की Golden SAML कमजोरी खोजने के बाद उन्होंने वर्षों तक कार्रवाई की मांग की, लेकिन कंपनी ने तुरंत fix करने के बजाय केवल दीर्घकालिक विकल्पों की बात की
- यह कमजोरी AD FS सर्वर की private key चोरी होने के बाद नकली tokens के जरिए सामान्य यूज़र की तरह cloud services तक पहुंच दिलाती है, audit logs में कम निशान छोड़ती है और multi-factor authentication को भी bypass कर सकती है
- Harris द्वारा सुझाया गया seamless SSO disable करना federal government ग्राहकों की असुविधा, Pentagon cloud contract, Okta से प्रतिस्पर्धा और user experience खराब होने की चिंताओं से टकराया
- 2020 में SolarWinds हमले के बाद रूसी hackers ने इस कमजोरी का इस्तेमाल कर National Nuclear Security Administration, NIH, Treasury Department आदि से संवेदनशील data इकट्ठा किया, और Microsoft ने बाद में Microsoft 365 ग्राहकों को AD FS का seamless SSO disable करने की सलाह दी
- Microsoft ने कहा कि customer protection उसकी सर्वोच्च प्राथमिकता है और security issues की कई बार समीक्षा की गई, लेकिन पूर्व कर्मचारियों की गवाही security culture और business priorities के टकराव का मामला दिखाती है
AD FS में खोजी गई Golden SAML कमजोरी
- Andrew Harris Microsoft में संवेदनशील ग्राहकों के hacking incidents पर response देने वाले गुप्त संगठन Ghostbusters में काम करते थे, और 2016 में एक बड़ी अमेरिकी technology company के breach की जांच करते हुए AD FS issue पर केंद्रित हुए
- AD FS एक product है जो user को एक बार login करने के बाद कई work programs तक access देता है, और इसे लाखों लोग इस्तेमाल करते हैं
- Harris ने जो मुख्य risk पहचाना, वह यह था कि SAML-based authentication में attacker खुद को वैध employee की तरह दिखाकर cloud-based programs तक access कर सकता है
- attacker पहले on-premises server में घुसता है और फिर AD FS server से private key निकालता है
- इसके बाद tokens forge करके वह high-privilege user जैसा दिख सकता है
- login information सामान्य जैसी दिखती है, इसलिए सामान्य audit logs से इसे detect करना मुश्किल होता है
- Harris का मानना था कि यह समस्या केवल Microsoft Azure ही नहीं, बल्कि Amazon जैसे अन्य cloud providers इस्तेमाल करने वाले संगठनों को भी प्रभावित कर सकती है
“security boundary” और MSRC का निर्णय
- Harris ने यह issue Microsoft Security Response Center, यानी MSRC, को बताया, लेकिन MSRC ने तय किया कि यह fix करने योग्य मामला नहीं है
- MSRC का मानना था कि attacker को पहले on-premises server तक access चाहिए, इसलिए वही point security boundary है, और उसके बाद cloud में जाने वाली समस्या अलग security boundary नहीं है
- पूर्व MSRC कर्मचारियों ने कहा कि उस समय center staff shortage के बीच बहुत-सी vulnerability reports संभाल रहा था, और “won’t fix” निष्कर्ष पर पहुंचने की संस्कृति थी
- उन्होंने याद किया कि उस समय “security boundary” शब्द स्पष्ट रूप से define नहीं था, और Microsoft इसे fix न करने की वजह के तौर पर अक्सर इस्तेमाल करता था
- Bill Gates ने 2002 के memo में लिखा था कि features जोड़ने और security issues हल करने के बीच चुनाव हो तो security को चुनना चाहिए, लेकिन पूर्व कर्मचारियों के मुताबिक समय के साथ MSRC का प्रभाव कमजोर हो गया
अस्थायी समाधान business logic से टकराया
- Harris ने माना कि long-term fix में समय लग सकता है, और अस्थायी समाधान के रूप में seamless single sign-on(SSO) disable करने का सुझाव दिया
- यह feature Microsoft की convenience सुविधा है, जिससे user एक बार login करने पर on-premises servers और कई cloud services तक access कर सकता है
- Harris के अनुसार product प्रभारी Mark Morowczynski ने इसका विरोध किया, यह कहते हुए कि कमजोरी का खुलासा attackers को संकेत दे सकता है और federal government ग्राहकों को बड़ी असुविधा हो सकती है
- federal government employees को नियमों के अनुसार smart cards से login करना पड़ता था
- Harris ने समझाया कि seamless SSO बंद करने पर cloud access के समय second login चाहिए होता, और उस प्रक्रिया में अनिवार्य smart card इस्तेमाल नहीं हो पाता
- Pentagon के बड़े cloud contract और Okta से प्रतिस्पर्धा को भी विरोध के कारणों में गिनाया गया
- Microsoft उस समय Okta से प्रतिस्पर्धा कर रहा था, और seamless SSO Microsoft की competitive advantages में से एक था
- Harris के सुझाव से users को दो बार authenticate करना पड़ता, जिससे friction पैदा होता और product strategy से टकराव होता
- Harris ने याद किया कि Morowczynski ने इस फैसले को technical decision नहीं, बल्कि business decision कहा था
बाहरी security firms की चेतावनियां
- CyberArk ने 2017 में इस technique को Golden SAML कहने वाला blog post और proof of concept प्रकाशित किया
- Brad Smith ने बाद में Senate Intelligence Committee को लिखित जवाब में लिखा कि Microsoft को इस issue के बारे में 2017 में CyberArk disclosure के समय पता चला
- CyberArk के Lavi Lazarovitz ने कहा कि disclosure से पहले कई कंपनियों के security researchers वाली private WhatsApp chat में यह issue share किया गया था, और उसमें Microsoft researcher भी शामिल था
- Harris ने कहा कि CyberArk disclosure के बाद यह issue और urgent हो गया, इसलिए उन्होंने इसे product group और MSRC के सामने फिर उठाया, लेकिन MSRC ने अपना पुराना रुख बनाए रखा
- 2019 में Mandiant researchers ने एक German conference में AD FS compromise के जरिए cloud accounts और applications तक access पाने का तरीका demonstrate किया और tool भी public किया
- Mandiant ने कहा कि presentation से पहले उसने Microsoft को सूचित किया था
- यह लगभग 16 महीनों में दूसरी बार था जब किसी बाहरी firm ने Microsoft को SAML issue के बारे में बताया
Harris की customer warning और NYPD मामला
- Harris ने 2019 में LinkedIn पर indirect warning पोस्ट की कि अगर आपका कोई परिचित AD FS authentication relationships को नहीं समझता, तो वह उनसे संपर्क करे
- उन्होंने उन customers को सीधे risk बताने की कोशिश की जिनसे उनके मौजूदा संबंध थे, और उनमें से एक New York Police Department था
- Harris ने NYPD के IT प्रमुख Matthew Fraser को AD FS कमजोरी समझाई और seamless SSO disable करने की सलाह दी
- Fraser ने उस meeting की पुष्टि की और कहा कि SAML कमजोरी को protection और isolation की जरूरत वाले क्षेत्र के रूप में पहचाना गया था
- Harris ने अगस्त 2020 में Microsoft छोड़कर CrowdStrike join किया, और कहा कि exit interview में भी उन्होंने SAML कमजोरी फिर उठाई
multi-factor authentication bypass और SolarWinds हमला
- Harris ने कहा कि 2018 में एक colleague से बातचीत के दौरान उन्हें पता चला कि forged token वाला attacker multi-factor authentication भी bypass कर सकता है
- समस्या यह थी कि additional security steps होने पर भी, forged token के साथ attacker उन सभी को skip कर सकता है
- 2020 के अंत में SolarWinds हमला public हुआ, और अमेरिकी सरकार ने कहा कि इसमें Russian state-backed hackers शामिल थे
- attackers ने SolarWinds software update में malware डालकर networks में backdoor access हासिल किया, और फिर Golden SAML जैसी post-compromise vulnerabilities का उपयोग कर cloud data और emails चुराए
- attackers ने Harris द्वारा बताई गई कमजोरी का इस्तेमाल कर कई agencies का संवेदनशील data इकट्ठा किया
- National Nuclear Security Administration
- National Institutes of Health
- Treasury Department के कई email accounts
- उस समय CISA के Brandon Wales ने कहा कि victims में से लगभग एक-तिहाई SolarWinds software इस्तेमाल नहीं करते थे
- Microsoft भी breached हुआ, और हमले के तुरंत बाद Microsoft ने Microsoft 365 customers को AD FS और समान products में seamless SSO बंद करने की सलाह दी
Microsoft का public stance और follow-up actions
- Microsoft President Brad Smith ने 2021 में Congress में कहा कि SolarWinds हमले में Microsoft products या services की कोई vulnerability exploit नहीं हुई
- Smith ने बताया कि Golden SAML Microsoft द्वारा पहचाने गए 60 मामलों में से 15% में इस्तेमाल हुआ, लेकिन यह भी स्वीकार किया कि observed या stolen data वाले victims केवल वही नहीं थे
- Smith ने कहा कि अगर organizations ने Microsoft Defender जैसे antivirus products खरीदे होते और Intune से devices protect किए होते, तो नुकसान लगभग नहीं होता
- SolarWinds के बाद Microsoft ने SAML risk कम करने के लिए कदम उठाए, और hacking के प्रभावों को efficient ढंग से detect करने वाली capability paid add-on product Sentinel में शामिल की गई
- Microsoft ने blog में detection की इस कमी को “blind spot” कहा
Microsoft का rebuttal और security culture विवाद
- Microsoft ने Brad Smith सहित senior executives को interview के लिए उपलब्ध नहीं कराया, लेकिन ProPublica की investigation findings को खुद खारिज नहीं किया
- कंपनी ने written response में कहा कि customer protection हमेशा सर्वोच्च प्राथमिकता है, और security response team हर issue को गंभीरता से लेती है तथा manual assessment और engineering व security partners की review से गुजरती है
- Microsoft ने बताया कि potential threats का आकलन करते समय customer disruption की संभावना, exploitability और available mitigations पर विचार किया जाता है
- 2023 में China government से जुड़े hackers द्वारा Microsoft security flaws exploit करके वरिष्ठ अमेरिकी अधिकारियों के emails तक access पाने की घटना भी House Homeland Security Committee की जांच के दायरे में आई
- Cyber Safety Review Board ने इस घटना की जांच में निष्कर्ष निकाला कि Microsoft की security culture अपर्याप्त है और व्यापक बदलाव की जरूरत है
- Satya Nadella ने board report के बाद कर्मचारियों से कहा कि अगर security और दूसरी priorities में टकराव हो, तो security को चुनें
cloud business competition और परिणाम
- 2014 में CEO बने Satya Nadella ने Microsoft का भविष्य Azure cloud business पर लगाया, और उस समय Azure Amazon से काफी पीछे था
- Microsoft ने enterprise और government customers को hybrid cloud strategy प्रस्तावित की, जिसमें on-premises servers का कुछ हिस्सा रखते हुए अधिकांश computing को cloud में ले जाना था
- security cloud sales की मुख्य logic थी, और यह फायदा बताया गया कि dedicated security staff patches और updates संभालेंगे
- Harris और पूर्व कर्मचारियों ने कहा कि Pentagon का बड़ा cloud contract और Azure growth pressure product team के decision-making को प्रभावित कर रहे थे
- Microsoft ने अंततः Amazon, Google और Oracle के साथ Defense Department के multi-year, multi-billion-dollar cloud business का एक हिस्सा जीता
- SolarWinds disclosure के बाद Microsoft का share price 106% बढ़ा, और इसके प्रमुख कारणों में Azure और ChatGPT जैसे AI products की सफलता बताई गई
- Morowczynski ने 2017 में Harris से जिस AD FS replacement long-term product का जिक्र किया था, वह 2022 में उपलब्ध होना शुरू हुआ
1 टिप्पणियां
Hacker News की राय
समाधान यह है कि संगठन के भीतर पूरी तरह zero trust लागू किया जाए और नेटवर्क पर भरोसा न किया जाए। internal network को भी external की तरह, यानी शत्रुतापूर्ण environment की तरह treat करना चाहिए
Google, BeyondCorp के साथ zero trust को बड़े पैमाने पर अपनाने वाले शुरुआती उदाहरणों में था, और मेरा मानना है कि Aurora के बाद Google के internal organization में कोई breach नहीं हुआ
पूरी तरह managed endpoints, मजबूत endpoint hardening, संगठन के सभी resources की inventory, device-specific certificates, और प्रति-user resource access तय करने वाला access control list engine चाहिए
काम के समय जैसी heuristics से anomalies भी detect की जा सकती हैं, और Google की internal apps सभी internet पर exposed हैं और SSO portal पर redirect करती हैं, लेकिन असल में उनमें प्रवेश नहीं किया जा सकता। ऐसी security problems का बड़ा हिस्सा पहले ही solve हो चुका है; बस implement करना है
ज्यादातर बड़े organizations ने दशकों से internal और external technologies की परतें जमा की हैं, पुराने systems लगभग unattended पड़े हैं, और mergers/acquisitions तथा departments को tools चुनने की आजादी के कारण heterogeneity बहुत ज्यादा है
zero trust पर जाने के लिए बड़े पैमाने की migration, अड़ियल IT लोगों को मनाने वाली “education”, और Google-style centralized model में बदलाव चाहिए
पहले दो को budget मिल भी जाए तो तीसरा बहुत महंगा हो सकता है। Google द्वारा बहुत सी चीजों को बंद करने की एक वजह यह भी है कि centralized model में लगातार migrations और breaking upgrades करने पड़ते हैं
startup में ऐसी best-practice आधारित uniformity customers को देना चाहता हूं, लेकिन किसी दिन customer “zero trust बंद करके IP allowlist इस्तेमाल करने दो” मांग सकता है। बड़े contract के लिए इसे मानना है या नहीं, यह दुविधा हो सकती है, और सिर्फ इसलिए acquisition cancel भी नहीं किया जा सकता कि जिस company को acquire कर रहे हैं उसके पास zero trust नहीं है
बल्कि ज्यादातर के लिए ये बेहद कठिन काम हैं, और “बस पूरी उल्लू की drawing बना दो” जैसी सलाह लगती है। उदाहरण के लिए कल्पना करें कि 22,000 employees वाली अमेरिका की सबसे बड़ी carpet और flooring manufacturer Shaw Industries यह सब करती है
अगर आपका रवैया absolute रूप से “safe” होने का है, तो आप breaches को मेहनत से ढूंढना छोड़ देंगे, और आखिरकार किसी दिन होने वाले breach को miss कर देंगे
zero trust एक philosophy है और काफी अच्छी philosophy है, लेकिन अपने आप में solution नहीं है। इसे absolute solution की जगह philosophy और अच्छी practices के रूप में सोचना बेहतर है
मुझे नहीं लगता यह architecture हर company के लिए सही है। ज्यादातर non-software technology companies को simple social engineering, scam emails, और credentials third parties को दे देने जैसी समस्याओं से नुकसान होता है, और economic espionage भी बड़ा खतरा है
Google के पास whistleblowers या management vision से टकराने वाले activist groups जैसी अलग security concerns भी हो सकती हैं, और उन समस्याओं के लिए यह structure सही हो सकता है। लेकिन इसका मतलब यह नहीं कि हर company के threat vectors समान हैं
security problems solve की जा सकती हैं, लेकिन जरूरी infrastructure मामूली नहीं है, और engineering के लिए इस्तेमाल होने वाले कई software stacks third-party authentication को support ही नहीं करते
developers, भले ही software developers न हों, अक्सर “managed endpoints” से कतराते हैं। यह Google में काम करता है, लेकिन एक special case जैसा है; व्यवहार में reasonable network segmentation कहीं ज्यादा प्रभावी हो सकती है
security और profit के बीच incentive mismatch खासकर public companies में बड़े cultural change के बिना ठीक करना मुश्किल है। यह भी नहीं पता कि ऐसा बदलाव किस चीज से trigger होगा
मैंने कई roles में cybersecurity को साथ-साथ संभाला है, लेकिन इसे full-time career न बनाने की वजह industry में firsthand देखी हुई चीजें हैं। असल अच्छी security practices की तुलना में compliance पर बेहद ज्यादा focus होता है, और वे standards भी अधूरे या weakly enforced होते हैं
cultural change जरूरी है, लेकिन मेरा मानना है कि वह customers की तरफ से आना चाहिए। consumers के लिए यह कठिन हो सकता है, लेकिन अगर enterprise customers security को ठीक से evaluate करें, binding guarantees मांगें, और उसी आधार पर purchasing decisions लें, तो industry response देगी
बेशक Microsoft desktop market में इतनी गहराई से जमी हुई है कि यह तरीका पूरी तरह effective होना मुश्किल है
हालांकि यह security की परवाह करने वाली culture change न होने की सीधी प्रतिक्रिया भी है। security teams के पास आम तौर पर केवल दो choices होती हैं
“security important है, इसलिए safe product बनाते हैं” कहकर मजाक उड़वाना, या auditors द्वारा मांगी गई compliance को आगे रखकर थोड़ा सा ही सही, organization को security की ओर move कराना
व्यक्ति भी कभी-कभी security के बजाय पैसा चुनते हैं। सरकार ने भी ज्यादा cost और कम productivity के बजाय अधिक productive workforce चुनी हो, ऐसा लगता है
जब कंपनियां सरकारों को बेचती हैं, तो कमाई और प्रचार का असर इतना बड़ा होता है कि असुविधाजनक सच छिपाने का incentive बन जाता है। एक खास aircraft manufacturer याद आता है
यह थोड़ा शर्मनाक चीजें छिपाने के स्तर से लेकर विशाल, व्यवस्थित और जानबूझकर की गई धोखाधड़ी तक, समय के साथ पूरे दायरे में फैल सकता है
अगर leader कहता है “security/quality को प्राथमिकता दो” लेकिन असल में उसका reward नहीं देता, तो खेल पहले ही सेट हो चुका होता है
रोज़ पैसे के targets पर reward या punishment देते हुए, कभी पकड़े जाने पर सिर्फ एक-दो junior लोगों को सज़ा दी जाए, तो कंपनी जिसके प्रति सचमुच गंभीर है वह पैसा है, security/quality नहीं
लक्ष्य हासिल करवाने हैं तो incentives देने होंगे। Sales में stress भी ज्यादा है और नौकरी जाना आसान हो सकता है, लेकिन सफल होने पर बड़ा पैसा मिल सकता है। Security में सफल होने पर बस नौकरी नहीं जाती, और असफल होने पर नौकरी चली जाती है
अच्छे security काम का नतीजा “कुछ नहीं हुआ” होता है—न breach, न disaster, न हंगामा—इसलिए इसे मापना भी मुश्किल है। अनुपस्थिति को संख्याओं में कैसे बदलें, यही समस्या है
आखिरकार sales के पास बहुत गाजरें हैं और डंडा सबके जैसा है, लेकिन security के पास गाजर नहीं, सिर्फ डंडा है, और वह डंडा कीलों वाला डंडा भी हो सकता है। जवाब culture में है, और मुझे लगता है culture बदलना सबसे कठिन है
Sales से यह उम्मीद नहीं करनी चाहिए कि वे security की चिंता करें; sales का focus growth होना चाहिए। समस्या यह है कि दूसरी तरफ को यह कहने का अधिकार और jurisdiction नहीं दिया जाता कि security fixes नए features से पहले आने चाहिए
अगर growth incentives पाने वाला project manager priorities तय करे, तो वह स्वाभाविक रूप से security की जगह growth चुनेगा
ऐसा नहीं कि security team को समस्या पता नहीं है; बल्कि fixes priority नहीं बनते और culture व process दोनों पक्षों के बीच संतुलन नहीं बना पाते
सरकार की तरफ भी, कम से कम individual decision-makers के career के लिए, contract पूरा होने की अच्छी-खासी incentive होती है
दोनों पक्ष चाहते हैं कि deal हो जाए, और जब तक end user retirement से पहले पकड़ न ले, defects छिपाने की motivation रहती है
Satya Nadella ने कहा था, “अगर security और दूसरी priorities के बीच चुनना पड़े, तो जवाब साफ है। security करो।” मुझे लगता है Microsoft का security-first model कुछ ऐसा है
Windows के हर कोने में ads ठूंस दो, user जो कुछ भी करता है उसे record करने वाला recorder install करो, और employees को “security करो” वाला mail भेज दो—बस mission complete
उससे यह बात जोर से महसूस हुई कि training, emails और processes का ज्यादातर हिस्सा plausible deniability के लिए है
Microsoft में ऐसे लोग भी हैं जो security की सच में परवाह करते हैं। मैं उनसे मिला भी हूं। लेकिन कुल मिलाकर ये mechanisms Satya को court या Congress में यह कहने लायक बनाते हैं कि “हमने security बेहतर करने को कहा था। गलती product team या individual contributor की है, Microsoft की policies और incentives की नहीं”
email की wording का कोई वजन नहीं होता। जिस पल leader security को किसी और चीज़ के बदले trade करने का चुनाव करता है, employees को जरूरी signal मिल चुका होता है
Canonical ने Super key search record किया था—उस controversy—और Ubuntu में Amazon ads default रूप से शामिल होने की बात याद आती है
जिन्हें computers पसंद हैं वे Arch, Gentoo, NixOS Minimal install करके packages audit कर सकते हैं, लेकिन ज्यादातर non-software engineers से ऐसा करने की उम्मीद करना अवास्तविक है
सिर्फ Microsoft ही नहीं, हर company के पास हमेशा जितने ज्यादा ads लगा सकें और जितना ज्यादा data collect कर सकें, उसका incentive होता है। मैं regulation का समर्थन करूं या नहीं, इस पर निश्चित नहीं हूं, लेकिन कोई और तरीका भी ठीक से नहीं दिखता
हमेशा की तरह “security first” जैसी executives की घिसी-पिटी बातों का कोई महत्व नहीं है
अगर features के लिए लोगों को reward और promote किया जाता है, लेकिन security culture को reward नहीं किया जाता, तो लोग और management layer मूर्ख नहीं हैं—वे उसी दिशा में optimize करेंगे
इस incentive को कैसे design किया जाए कि समस्या हल हो, यह मुझे नहीं पता, लेकिन चीजें इसी तरह चलती रहेंगी
जब तक जिम्मेदार व्यक्ति को सज़ा नहीं मिलती और कोई कीमत नहीं चुकाता, शायद कुछ नहीं होगा
आम तौर पर कोई feature product में तब जाता है जब marketing दिखा दे कि वह feature अपनी cost से ज्यादा business growth लाता है। वही idea लागू किया जा सकता है
जैसे, “यह vulnerability X% customers को प्रभावित करती है, Y% छोड़कर चले जाएंगे, और reputation damage तक होगा, जिससे बड़ी रकम का नुकसान होगा। दूसरी तरफ इसे Z दिनों में छोटी रकम में ठीक किया जा सकता है। फैसला?”
मुझे लगता है कि इस कहानी में एक काफ़ी बड़ा संकेत नज़रअंदाज़ हो रहा है। Seamless SSO को disable करने से उन physical smart cards पर व्यापक और खास असर पड़ता है जिनका इस्तेमाल सरकारी कर्मचारी डिवाइस में login करने के लिए करते हैं
संघीय नियमों के तहत ज़रूरी ये cards हर login पर random password बनाते हैं, लेकिन underlying technology configuration की वजह से Seamless SSO हटाने पर users smart card से cloud access नहीं कर पाते
अमेरिकी सरकार Microsoft के सबसे बड़े ग्राहकों में से एक है, और उसका user base और Active Directory scale भी बहुत बड़ा है। इस क्षेत्र में काम करने के अनुभव से कहूँ तो user और role management, चोरी हुए credentials, locked accounts आदि के कारण लगभग nightmare जैसा होता है और लगातार target बनता है
अमेरिकी सरकार ऐसी समस्याएँ घटाने के लिए सभी को smart card authentication पर ले जाने की कोशिश करती रही है, और passwords हटाकर सभी को 2-factor authentication पर बदल देने से attack surface काफ़ी कम हो जाता है
लेकिन इस व्यक्ति ने fix के हिस्से के रूप में ग्राहकों से बस इसे बंद करने को कहने जैसा सुझाव दिया
मैं मूल SAML flaw के खतरे को नकार नहीं रहा, लेकिन मुझे लगता है कि Harris ने Microsoft की बाकी प्रतिक्रिया को unfair तरीके से आँका। उसने मानो पूरी agency में 2-factor authentication बंद करने की माँग की हो
short-term mitigation सुरक्षा को काफ़ी नुकसान पहुँचाता, और ग्राहकों को उसी तरह के हमलों के लिए ज़्यादा expose कर सकता था जिन्हें वे असल में रोकना चाहते थे। इस कहानी को कंपनी द्वारा सुरक्षा की परवाह न करने के एक और उदाहरण की तरह पेश किया गया, लेकिन यह ग्राहक की overall security posture को संकीर्ण नज़रिए से देखने वाले “whistleblower” की प्रतिक्रिया लगती है
ज़्यादातर सरकारी agency के information security system administrators भी इसी वजह से कहते कि यह viable option नहीं है
आखिर लेख का सार भी यही है। उन्हें पता था कि इसे सुरक्षित तरीके से manage करने का कोई रास्ता नहीं है, फिर भी वे बेचते रहे
Microsoft का बचाव करने की कोशिश नहीं है, लेकिन मुझे नहीं पता कि क्या आप ऐसी कंपनी का नाम साफ़-साफ़ बता सकते हैं जो लाभ से ज़्यादा सुरक्षा को प्राथमिकता देती हो
Bill Gates ने 2002 में कहा था कि “अगर features जोड़ने और security issues हल करने में से चुनना पड़े, तो security चुननी चाहिए,” और Satya Nadella ने भी 2024 में इसी तरह “security करो” कहा था
https://www.wired.com/2002/01/bill-gates-trustworthy-computi...
https://www.theverge.com/24148033/satya-nadella-microsoft-se...
वास्तव में ऐसी features हैं जिन्हें मैं इस्तेमाल करता और जिनके लिए ज़्यादा पैसे देता, लेकिन वे उन्हें इसलिए नहीं बनाते क्योंकि protocol पूरी तरह सुरक्षित नहीं है या उन्हें common calendar clients के साथ integrate करना पड़ेगा
अगर paying customer security को value नहीं देता, तो regulation या legal requirement न होने तक vendor भी security को value नहीं देगा
लेकिन यह देखते हुए कि बड़े organizations और governments Microsoft के customers हैं, यह मामला अजीब है। शायद “हमारे साथ ऐसा नहीं होगा” या “किसी को पता नहीं चलेगा” वाला अहंकार रहा हो
अब वे शायद देख रहे होंगे कि reputation को नुकसान आगे के profits को भी नुकसान पहुँचा सकता है
कल्पना कीजिए कि किसी contractor ने एक बड़ा पुल बनाया। एक internal safety inspector ने अपने bosses को बार-बार structural flaw के बारे में चेतावनी दी जो collapse का कारण बन सकता था, और समय के साथ बाहर से भी दो बार public warnings आईं, लेकिन कंपनी ने उसकी गंभीरता कम करके दिखाई
आखिर पुल गिर जाता है, और यह सामने आता है कि कंपनी ने इसलिए कुछ नहीं किया क्योंकि वह और defective bridges बेचने के contracts खोना नहीं चाहती थी
जनता का गुस्सा जायज़ होगा और संबंधित लोगों को legal consequences भुगतने पड़ेंगे। लेकिन मुझे समझ नहीं आता कि हमारी industry में ऐसा क्या अलग है कि कंपनी और managers ऐसी bad faith हरकत से बच निकलते हैं
लगता है जब तक पर्याप्त लोगों की जान नहीं जाती, सामान्य तौर पर लोग बहुत परवाह नहीं करते
https://www.nrk.no/innlandet/statens-vegvesen-legg-fram-rapp...
Software तुरंत जानलेवा नहीं होता। इसलिए medical और aerospace को छोड़कर यह लगभग Wild West की तरह चलता है
personal information का internet पर leak होना भयानक है, लेकिन airplane door के टूटकर अलग हो जाने की तुलना में फिर भी कार्रवाई करने के लिए समय होता है
सरकार, government को बेचे जाने वाले software products के contracts में licensed individuals के signature और approval को अनिवार्य करके बदलाव शुरू कर सकती है
Mottarone cable car तो निश्चित रूप से मिलता-जुलता था। safety device disable करके उसे वर्षों तक चलाया गया, और जब haul rope टूटी तो cabin नीचे जा गिरा और सभी passengers मारे गए
Golden SAML किसी vulnerability से ज़्यादा, जैसा कि लेख में उद्धृत CyberArk का लेख भी फिर से कहता है, ऐसा attack type है जो पहले बॉक्स पर पूरी तरह कब्ज़ा करने के बाद ही संभव होता है
अगर मैंने कुछ गलत नहीं समझा है, तो कोई खास flaw नज़र नहीं आता। Microsoft को article में जिस तरह मज़ाक में कहा गया है, उस हिसाब से यह security boundary पार करना नहीं है
SSO में हमेशा ऐसे trade-off होते हैं। अगर SSO infrastructure compromise हो जाए, तो उसका इस्तेमाल करने वाली हर चीज़ compromise होने के जोखिम में होती है
इस हिस्से को सरसरी तौर पर आगे बढ़ा दिया जाता है, लेकिन असली “hacking” शायद उसी के करीब है
जब तक SSO इस्तेमाल कर रहे हैं, mitigation भी आसान नहीं है। एक तरीका यह है कि target service valid SAML token के अलावा 2nd factor मांगे, लेकिन तब हर user को हर target service के लिए अपना 2nd factor up to date रखना होगा
यह जल्दी ही manage करना असंभव हो जाता है, और SSO और 2nd factor दोनों को साथ support करने वाले SaaS या self-hosted apps भी practically बहुत कम हैं
यह “GOLDEN ADMIN” नाम का attack बनाने जैसा है। मतलब अगर आपके पास admin credentials हैं, तो admin के तौर पर login करके जो चाहें कर सकते हैं
attacker का बिना logs छोड़े कहीं भी authenticate कर पाना बुरा है, यह मैं समझता हूं, फिर भी original comment से सहमत हूं
मुझे लगता है कि संभावित तरीके मौजूद हैं
यह सिर्फ Microsoft की समस्या नहीं है। security engineer के तौर पर, अगर इस career में अपनी sanity और performance दोनों चाहिए, तो ऐसी जगह काम करना होगा जहां technical capability हो, strong regulatory incentives और budget हों, या profit से strongly linked threat model की वजह से security culture में गंभीरता हो
मेरे criteria में fit होने वाले मुख्य examples हैं: IPO से पहले के startups जिन्हें public listing के लिए SOC2 वगैरह pass करना पड़ता है, crypto industry जहां key theft जैसे threat models और profit incentives साफ़ हैं, और public technology companies जो core infrastructure का बड़ा हिस्सा provide करती हैं
हालांकि कुछ कंपनियां Microsoft जैसी भी होती हैं जो इतनी बड़ी हो जाती हैं कि fail नहीं हो सकतीं, और कुछ जगहें Google/Project Zero, Verizon/Paranoids, Cloudflare जैसी हैं जहां internal security teams मजबूत दिखती हैं
banks में पैसा है, risk-averse culture है और regulation मजबूत है, इसलिए possibility है, लेकिन healthcare में regulation मजबूत होने के बावजूद attack volume और apathy की वजह से मैं कभी काम नहीं करना चाहूंगा
इसलिए अगर आप DART team में real threat actors और diverse incident response बहुत देखना नहीं चाहते, या बहुत low-level OS security नहीं करना चाहते, तो security engineer के तौर पर Microsoft जाना recommend नहीं करूंगा
Apple security engineer का काम कैसा है, मुझे अच्छी तरह नहीं पता। security career में average tenure करीब 10 साल के आसपास होने की वजह भी यही है। sanity घिस जाती है, और compensation काफी अच्छा होता है, जिससे 30–40 की उम्र में बचाए हुए पैसों से कुछ और किया जा सकता है