- नेटवर्क defense की शुरुआत assets को list करने और प्राथमिकता देने से होती है, लेकिन असली attack surface assets के बीच security dependency graph के रूप में बनता है
- attackers सबसे मज़बूत asset पर सीधे हमला करने के बजाय, कमजोर तरीके से सुरक्षित workstation या management path के जरिए high-value assets तक bypass route खोजते हैं
- Windows नेटवर्क में logon method, credentials, Kerberos TGT, NTLM hash, common local administrator password, logon script जैसे तत्व सभी graph के edges बन सकते हैं
- defenders को asset list को graph में बदलना चाहिए और infrastructure segmentation·credential silo·least privilege·two-factor authentication·credential rotation से connectivity घटानी चाहिए
- attackers पुराने diagrams नहीं, बल्कि वास्तविक infrastructure को टुकड़ों में सीखते हैं; इसलिए defenders को मौजूदा network के connection relationships को अधिक सटीक रूप से समझना होगा ताकि बढ़त मिल सके
list-आधारित defense क्या चूक जाती है
- कई network defenses attackers से संपर्क होने से पहले ही battlefield को गलत समझने के कारण भटक जाते हैं
- defenders assets की रक्षा करने, priorities तय करने, और उन्हें workload व business function के अनुसार व्यवस्थित करने पर ध्यान देते हैं
- system management services, asset inventory databases, BCDR spreadsheets में asset lists भरी रहती हैं
- लेकिन वास्तव में defenders को जिस चीज़ से निपटना है, वह individual assets की list नहीं, बल्कि security relationships से जुड़े assets का graph है
- attackers spearphishing जैसी techniques से graph के किसी बिंदु पर उतरते हैं, फिर कमजोर systems खोजकर network के भीतर आगे बढ़ते हैं
- यह graph बाहर से दिया हुआ नहीं होता; इसे network design और operate करने वाले defenders खुद बनाते हैं
network के भीतर graph का मतलब
- network का graph assets के बीच equivalence classes बनाने वाली security dependencies का collection है
- graph को प्रभावित करने वाले factors मोटे तौर पर चार हैं
- network design
- network management का तरीका
- network में इस्तेमाल होने वाले software और services
- users का behavior
- domain controller के उदाहरण में, एक कमजोर management path पूरे high-value asset की security level को घटा देता है
- Bob workstation से domain controller manage करता है
- अगर वह workstation domain controller जितना सुरक्षित नहीं है, तो domain controller भी compromise हो सकता है
- Bob के workstation पर administrator privileges रखने वाला कोई दूसरा account भी Bob और domain controller को compromise कर सकता है
- वे administrators काम के लिए एक या अधिक दूसरी machines में log on करते हैं
- attacker अगर उनमें से किसी एक को compromise कर दे, तो domain controller तक जाने का path बन जाता है
Six Degrees of Mallory: graph के साथ lateral movement
- attacker compromised machine पर इंतजार करते हुए mimikatz जैसे password dumper से high-value account के logon का इंतजार कर सकता है
- example graph का left cluster एक single Terminal Server है, जिसे सैकड़ों users इस्तेमाल करते हैं
- attacker अगर इस machine को compromise कर दे, तो समय के साथ कई users के credentials dump कर सकता है
- graph search से High Value Asset की ओर जाने वाले कई paths सामने आते हैं
- Terminal Server compromise होने से User46 और User128 भी compromise किए जा सकते हैं
- User46, Machine2821 का administrator है, और User128, Machine115 का administrator है
- उन workstations को compromise करने पर User1 और User34 को compromise किया जा सकता है
- User1 और User34 दोनों High Value Asset के administrators हैं
- High Value Asset को protect करने के लिए उस पर निर्भर सभी तत्वों को High Value Asset जितनी ही सख्ती से protect करना होगा, और वे मिलकर एक equivalence class बनाते हैं
security dependencies बनाने वाले relationships
- Windows network में जब user Interactive, Terminal Server आदि कोई specific logon करता है, तो underlying host compromise होने पर user के credentials चोरी के exposure में आ जाते हैं
- exposure में credentials के साथ Kerberos TGT, NTLM hash जैसे single sign-on equivalents भी शामिल होते हैं
- security dependency रोजमर्रा के management relationships से भी बनती है
- common password वाले local administrator accounts: एक system से local administrator password dump करने के बाद, उसी password का इस्तेमाल करने वाले दूसरे hosts पर उसे use किया जा सकता है
- बहुत से users के लिए execute होने वाले logon scripts रखने वाले file servers और software update servers
- इस्तेमाल के समय client machines तक print driver deliver करने वाले print servers
- smartcard logon के लिए valid certificates issue करने वाली certification authority
- privileged user के रूप में चल रहे database server context में code execute कर सकने वाला database administrator
- indirect relationships भी graph का हिस्सा बन जाते हैं
- vulnerability वाली machine compromise होने पर attacker graph में नए edges बना सकता है
- यदि किसी user के पास trust relationship न रखने वाले दो domains में एक ही password वाले accounts हैं, तो domains के बीच hidden edge बन जाता है
graph को घटाने के defense methods
- defender का पहला कदम asset list को graph में बदलकर network को visualize करना है
- इसके बाद unwanted edges को ढूंढकर graph को prune करना होगा, जो बड़ी connectivity explosion पैदा करते हैं
- infrastructure segmentation और credential silos implement करें
- administrators की संख्या घटाएं, और Just-In-Time / Just Enough techniques से privileges minimize करें
- specific edge movement को mitigate करने के लिए two-factor authentication का use करें
- user account compromise की स्थिति के लिए मजबूत credential rotation method लागू करें
- forest trust relationships की फिर से समीक्षा करें
attacker से बेहतर reality model बनाना
- battlefield visualize करते समय defenders को attackers को बढ़त नहीं देनी चाहिए
- defenders अपने network की पूरी जानकारी रख सकते हैं, लेकिन attackers को network टुकड़ों में सीखना पड़ता है
- attackers inaccurate mental model, incomplete asset inventory system, outdated network diagram नहीं, बल्कि वर्तमान में मौजूद infrastructure का अध्ययन करते हैं
- defenders भी reality के आधार पर network manage करें, तभी वे prepared defender mindset के करीब पहुंचते हैं
आगे पढ़ने के लिए
- Heat-ray: Combating Identity Snowball Attacks Using Machine Learning, Combinatorial Optimization and Attack Graph: J. Dunagan, D. Simon, A. Zheng
- Two Formal Analyses of Attack Graphs: S. Jha, O. Sheyner, J. Wing
- Using Model Checking to Analyze Network Vulnerabilities: P. Ammann, R. Ritchey
- A Graph-Based System for Network-Vulnerability Analysis: C. Phillips, L. Swiler
- Automated Generation and Analysis of Attack Graphs: J. Haines, S. Jha, R. Lippman, O. Sheyner, J. Wing
- Modern Intrusion Practices: Gerardo Richarte
- Attack Planning in the Real World: Jorge Lucangeli Obes, Gerardo Richarte, Carlos Sarraute
1 टिप्पणियां
Hacker News की राय
हमलावरों के पास आम तौर पर एक मिशन होता है, जैसे अहम डेटा लीक करना, लक्ष्य को अस्थिर करना, या ransomware; और वे मिशन पूरा होने तक जितनी ज़रूरत हो उतनी गहराई तक खोज कर सकते हैं
इसके उलट defender को एक साथ बहुत सारे signals और threat vectors ट्रैक करने पड़ते हैं, इसलिए वे list में सोचने को मजबूर होते हैं, और regulations की वजह से जिन items पर कार्रवाई करनी है उन्हें भी priority देनी पड़ती है
अगर defender को graph में इधर-उधर randomly रखकर दिलचस्प activity खोजने जैसा कोई तरीका न हो, तो समझ नहीं आता कि defender graph में कैसे सोच सकते हैं। लेखक ने जो सुझाव दिए हैं वे भी आखिरकार उन signals की list ही बनेंगे जिन्हें defender को cross-check करना होगा
जब defenders ने वह तरीका अपनाया, तो वे red team के execute करने से पहले संभावित attacks पहचान सके। समझदार teams, उदाहरण के लिए, AWS को graph की तरह crawl करके low-value account से high-value account तक जाने वाले paths खोजने वाली red-team technique तुरंत अपना लेंगी
यह zero-sum या बड़े बदलाव की बात नहीं है, लेकिन defenders भी attackers की तरह ज़्यादा सोच सकते हैं और attacker tools को defense में ज़्यादा बार इस्तेमाल कर सकते हैं
तब उस लक्ष्य तक जाने वाले path को protect करना होगा, चाहे वह path कैसा दिखता हो या software तक सीमित हो या नहीं
attacker किसी CVE का दुरुपयोग करके entertainment system को denial-of-service state में डाल सकता है, लेकिन असल में यह कितना important है, यह सवाल है
वास्तविक attacks की बड़ी majority “देखते हैं क्या मिल सकता है, फिर बाद में तय करेंगे कि उसका इस्तेमाल कैसे करना है” जैसी होती है। information gathering, influence operations, propaganda जैसी कई attack activities में भी यही लागू होता है
defenders lists इसलिए इस्तेमाल करते हैं क्योंकि उन्हें सैकड़ों, हजारों assets को एक साथ manage करना पड़ता है। जब बहुत सारी चीज़ें manage करनी हों, तो आप list बनाते हैं, उसे scan करते हैं, और checklist apply करते हैं
बेशक defenders को dependency graph भी बनाना चाहिए, लेकिन पहले list बनाकर यह verify करना चाहिए कि वह up to date है, limited trust मानती है, और resources isolated हैं, फिर dependency graph बनाना चाहिए
defender को list और graph दोनों के बारे में सोचना पड़ता है और बहुत बड़ी संख्या में items manage करने पड़ते हैं, जबकि attacker को बस कुछ चीज़ें देखनी होती हैं
अगर list को graph में बदलने वाली insight नहीं है, तो अंत में आपके पास बस core assets की list होगी और आप उन हजारों access paths को whack-a-mole की तरह बंद करते रहेंगे जिन पर आपने विचार ही नहीं किया
यह लेख कुछ ज़्यादा ही गहराई में चला गया लगता है। या वजह सही हो सकती है, लेकिन cause गलत। defender का काम खुद defense नहीं है
cyber security कोई sports match नहीं है जिसमें clear और बराबरी के goals हों और positions बारी-बारी से निभाई जाती हों; यह defender के main business के बगल में एक side event और distraction जैसा है
इसके उलट attacker का पूरा काम system पर attack करना है। attack को कमजोर करने वाला कोई और objective, secondary owner, या consideration नहीं होता
attacker इसलिए जीतता है जिस तरह Microsoft, Cisco से बेहतर operating system ship करता है। Cisco के लिए operating system एक साधन है, लेकिन Microsoft के लिए वह उद्देश्य है
यह भी समझाता है कि companies को data breach के लिए market में शायद ही सज़ा क्यों मिलती है
cyber attacks के साफ objectives होते हैं, जैसे data theft, service disruption वगैरह। यह उन immature actors पर फिट हो सकता है जो बस तोड़फोड़ और chaos पैदा करना चाहते हैं, लेकिन nation-state actors या पैसे से प्रेरित criminals को देखें तो यह पूरी तरह गलत perspective है
मुझे तो लगता है यह लेख उल्टा पर्याप्त गहराई तक नहीं गया :-)
“list” components का shorthand representation है, और “graph” interoperability का shorthand representation है। component perspective analysis है, और interaction perspective के लिए अभी कोई अच्छा शब्द नहीं है, लेकिन लेख में जैसा कहा गया है, वह अक्सर attack surface बन जाता है
complex adaptive systems में components और message bus होते हैं, और अहम बात यह है कि यह bus components को interoperate करने का तरीका देती है। आप चींटियों को एक-एक करके पकड़ सकते हैं, लेकिन अगर सच में रोकना है तो pheromone trail छोड़ने की क्षमता खत्म करनी होगी
interoperability के तरीकों को समझने के लिए भी “analysis” जैसा कोई शब्द होता तो अच्छा होता। Gestaltysis जैसा कुछ?
मैंने कुछ समय के लिए एक cybersecurity कंपनी में काम किया था, लेकिन मैं शब्दों में नहीं बता पाता था कि मुझे वह product क्यों नापसंद था और वह कंपनी व industry के बड़े हिस्से का approach आखिरकार नकली-सा क्यों लगता था
अब समझ में आ गया। हम cybersecurity की सबसे बेकार practice, यानी संगठन-स्तर की checklist को support करने वाले tools बना रहे थे
हर activity के केंद्र में lists और recurring schedules होते हैं। नियमित रूप से आकर जो करना है वह करना पड़ता है
बेशक, मैं मानता हूं कि उस “जो करना है” वाले चरण में ज्यादा गहरी और बेहतर approach की जरूरत होती है
यह कहने के लिए कि “हमने सभी checklists follow कीं और security software पकड़ नहीं पाया, इसलिए गलती हमारी नहीं है”
अगर कोई कंपनी सच में security की परवाह करती, तो signal-to-noise ratio 1% से कम वाले बेकार scanners पर पैसा खर्च करने के बजाय red team hire करती
aviation को देखें, तो pilots checklists के भरोसे जीते हैं। यह guarantee नहीं है कि flight के दौरान कभी समस्या नहीं होगी, लेकिन checklist follow न करना या उसे हल्के में लेना disaster को बुलावा देना है। ऐसी checklists वर्षों के महंगे अनुभव पर बनी होती हैं
लेकिन जो checklist सिर्फ यह कहने के लिए हो कि “checklist है”, या जिसे वास्तविक परिस्थितियों के हिसाब से नियमित रूप से review और update न किया जाए, वह निरर्थक है
कई कंपनियां इसे गलत समझती हैं। वे checklist को ही security मान लेती हैं, जबकि असल में checklist सिर्फ यह याद दिलाने का tool है कि जो काम पहले सही तरीके से किया गया था, उसे लगातार बनाए रखना है। जैसे ही checklist को goal की तरह treat करते हैं, रास्ता भटक जाते हैं
penetration tester के नजरिए से कहूं, तो attackers भी जरूरी नहीं कि graph में सोचते हों
BloodHound को छोड़कर graph इस्तेमाल करने वाले tools तुरंत याद नहीं आते
web security में भी “graph thinking” लागू होने का कोई उदाहरण याद नहीं आता। इसके बजाय test करने वाले attacks की list बहुत बड़ी होती है: https://portswigger.net/web-security/all-topics
और penetration test report में आखिरकार graph नहीं, बल्कि to-do list जाती है। जैसे SMB signing, सभी machines manage करने के लिए domain admin account का इस्तेमाल न करें, वगैरह
इस phrase के popular होने की मुख्य वजह यह है कि यह hacker community के ego को छूता है। “हम smart side हैं, और defenders बस Excel sheets से खेलते हैं” जैसा
हालांकि इसमें सच का एक टुकड़ा है। defenders काफी समय ऐसी चीजों पर खर्च कर सकते हैं जो बहुत जरूरी नहीं होतीं। जैसे सभी servers पर CIS benchmark हाथ से लागू करते हुए वे वे low-hanging fruit छोड़ देते हैं जो मजबूत security posture बना सकती थीं
कई कंपनियों में defenders बस system administrators होते हैं जिन्हें यह नहीं पता कि किस पर focus करना चाहिए
तुरंत याद आने वाला उदाहरण bug chain है। CVSS 4~7 स्तर की कुछ vulnerabilities को जोड़ने पर वे full remote code execution जैसे 9.8-level outcome में बदल सकती हैं। bugs को इस तरह जोड़ना मूल रूप से compromise elements के जरिए graph traversal ही है
BloodHound शानदार है और attack graph को conceptualize करने के लिए अच्छा visual tool है, लेकिन attacker के perspective से target domain को समझने की प्रक्रिया का सिर्फ एक हिस्सा है
web penetration testing में BloodHound जैसा साफ-सुथरा tool नहीं होने की वजह यह है कि compromise chains को सरल tool-form में reduce करना मुश्किल है। AD में security boundaries कुछ हद तक समझी और codify की गई हैं, लेकिन web apps की chains अक्सर underlying framework की बजाय उस application के लिए specific होती हैं
penetration test report में SMB signing या “DA account से सब कुछ manage न करें” जैसी items इसलिए आती हैं, क्योंकि वे compromise chain की बहुत early stage में चमकते हुए hot nodes होते हैं। असल दुनिया में अक्सर इसी तरह compromise होता है
मामला यह नहीं कि penetration tester graph thinking नहीं समझता, बल्कि कई बार graph का पहला node ही practically full compromise का मतलब होता है, इसलिए आगे traverse करने की वजह नहीं बचती
यह उस बात को बस stylish तरीके से कहना है कि defender को सभी entry points बचाने पड़ते हैं, जबकि attacker को सिर्फ एक कमजोरी ढूंढनी होती है
उदाहरण के लिए, क्या honeypots का इस्तेमाल करके zero-day exploits को attacker की machines पर वापस feed करना संभव नहीं होगा? यह Google, Microsoft आदि के products में जानबूझकर design किया गया भी हो सकता है
एक तरह की plausible deniability रखते हुए पूरी तरह blackhat जैसा जाना, और ransomware attackers को ransomware ही खिलाना
लिखते-लिखते यह SF में दिखने वाली evil omnipotent corporation जैसा लगने लगा है, हालांकि ऐसी corporations आम तौर पर दुश्मनों की हत्या तक करती हैं
मैंने incident response भी किया है और penetration testing व red team का अनुभव भी है। यह संक्षिप्त अभिव्यक्ति है, लेकिन कुछ हद तक सही है, और इसे लेख में दिखाए गए जितना negative होना जरूरी नहीं लगता
defense कई elements से मिलकर बनती है। उदाहरण के लिए security incidents के risk और impact को कम करने वाले effective controls develop करना, attacks और compromises identify करना, और incident response। standards और response की lists अच्छी तरह काम करती हैं
defense में ऐसे controls design करने के लिए network graph के बारे में सोचने वाले architecture decisions भी शामिल होते हैं। defense field भी architecture/engineering, risk management, incident response, application security, training, threat intelligence आदि में विविध है
यह भी दिलचस्प है कि लेखक ने यह संकेत दिया कि defense का list में सोचना problem है, और फिर defense improve करने के लिए consider करने वाली items की list पेश कर दी
attackers इसलिए जीतते हैं क्योंकि कमजोरी ढूंढने के बाद उन्हें सिर्फ एक बार successful होना होता है। defenders को सब कुछ एक साथ बचाना पड़ता है
लगता है हर network में intruders को पकड़ने के लिए कम से कम एक honeypot होना चाहिए। fake cryptocurrency credentials, fake password stores जैसी चीजें इसमें आती हैं