[{"content":"","date":null,"permalink":"https://puresecurity.com/hi/services/compliance/pci-dss-qsa-audit/","section":"सुरक्षा सेवाएं","summary":"","title":"PCI DSS 4.0.1 QSA ऑडिट एवं AOC सत्यापन"},{"content":"सक्रिय QSA और पूर्व CISO द्वारा सीधे संचालित अनुपालन कार्य, जिन्होंने 12 APAC न्यायालयों में 100 से अधिक वित्तीय संस्थानों के लिए केंद्रीय बैंक की परीक्षाओं को दोनों पक्षों से सफलतापूर्वक पास किया है।\nहम सत्यापित करते हैं कि कार्ड ब्रांड और नियामक वास्तव में क्या मांगते हैं, और हम मूल्यांकन किए जाने वाले क्षेत्र को छोटा करने से शुरुआत करते हैं, क्योंकि ऑडिट करने के लिए सबसे सस्ता नियंत्रण वह है जो कार्यक्षेत्र से बाहर है। यह स्तंभ भुगतान व्यवसायों, फिनटेक और विनियमित उद्यमों के लिए उपयुक्त है जिन्हें महीनों की देरी के बिना रक्षा योग्य सत्यापन की आवश्यकता होती है।\n","date":null,"permalink":"https://puresecurity.com/hi/services/compliance/","section":"सुरक्षा सेवाएं","summary":"","title":"PCI DSS और नियामक अनुपालन"},{"content":"","date":null,"permalink":"https://puresecurity.com/hi/services/technical/penetration-testing/","section":"सुरक्षा सेवाएं","summary":"","title":"मानव-नेतृत्व वाली पेनेट्रेशन टेस्टिंग"},{"content":"","date":null,"permalink":"https://puresecurity.com/hi/services/governance/vciso-advisory/","section":"सुरक्षा सेवाएं","summary":"","title":"वर्चुअल CISO (vCISO) सलाहकार सेवा"},{"content":"","date":null,"permalink":"https://puresecurity.com/hi/services/compliance/pci-dss-gap-assessment/","section":"सुरक्षा सेवाएं","summary":"","title":"PCI DSS गैप मूल्यांकन एवं स्कोप रिडक्शन"},{"content":"इंजीनियरिंग कार्य एक ऐसे इंजीनियर के नेतृत्व में किया जाता है जिसने राष्ट्रीय महत्वपूर्ण बुनियादी ढांचे की रक्षा की है और 24x7 सुरक्षा संचालन केंद्र (SOC) चलाया है, न कि केवल दूसरों के सिस्टम का मूल्यांकन किया है।\nनिष्कर्ष सत्यापित साक्ष्य, पुनरुत्पादन चरणों और सुधार को बनाए रखने के लिए आवश्यक स्वचालन के साथ आते हैं। यह स्तंभ इंजीनियरिंग-आधारित संगठनों के लिए आदर्श है जो ऐसा सुरक्षा कार्य चाहते हैं जिसे वे प्रोजेक्ट समाप्त होने के बाद स्वयं चला सकें, परीक्षण कर सकें और बनाए रख सकें।\n","date":null,"permalink":"https://puresecurity.com/hi/services/technical/","section":"सुरक्षा सेवाएं","summary":"","title":"तकनीकी सुरक्षा एवं इंजीनियरिंग"},{"content":"","date":null,"permalink":"https://puresecurity.com/hi/services/governance/third-party-risk-management/","section":"सुरक्षा सेवाएं","summary":"","title":"तृतीय-पक्ष जोखिम प्रबंधन (TPRM)"},{"content":"","date":null,"permalink":"https://puresecurity.com/hi/services/technical/linux-hardening/","section":"सुरक्षा सेवाएं","summary":"","title":"लिनक्स एवं इंफ्रास्ट्रक्चर हार्डनिंग"},{"content":"","date":null,"permalink":"https://puresecurity.com/hi/services/technical/api-application-security-review/","section":"सुरक्षा सेवाएं","summary":"","title":"API एवं एप्लिकेशन सुरक्षा समीक्षा"},{"content":"","date":null,"permalink":"https://puresecurity.com/hi/services/technical/configuration-architecture-assessment/","section":"सुरक्षा सेवाएं","summary":"","title":"कॉन्फ़िगरेशन एवं आर्किटेक्चर मूल्यांकन"},{"content":"","date":null,"permalink":"https://puresecurity.com/hi/services/compliance/regulatory-compliance/","section":"सुरक्षा सेवाएं","summary":"","title":"नियामक अनुपालन एवं फ्रेमवर्क संरेखण"},{"content":"जवाबदेही से युक्त सुरक्षा नेतृत्व: सुरक्षा रोडमैप का स्वामित्व, ऑडिट और एंटरप्राइज ग्राहक समीक्षाओं का नेतृत्व, और आपके बोर्ड के समक्ष सुरक्षा का प्रतिनिधित्व। यह सलाह एक पूर्व CISO से आती है जिसने बोर्ड को रिपोर्ट किया है, CFO के सामने बजट का बचाव किया है और केंद्रीय बैंक के परीक्षकों को जवाब दिया है, इसलिए भाषा बिल्कुल वैसी ही होती है जैसी आपके हितधारक सुनना चाहते हैं।\nयह स्तंभ उन उभरती कंपनियों के लिए उपयुक्त है जिन्हें बड़े एंटरप्राइज सौदे जीतने के लिए विश्वसनीय सुरक्षा नेतृत्व की आवश्यकता है, और स्थापित संगठनों के लिए जिन्हें पूर्णकालिक कार्यकारी की लागत और लंबी भर्ती प्रक्रिया के बिना एक स्वतंत्र वरिष्ठ दृष्टिकोण की आवश्यकता है।\n","date":null,"permalink":"https://puresecurity.com/hi/services/governance/","section":"सुरक्षा सेवाएं","summary":"","title":"रणनीतिक शासन एवं नेतृत्व"},{"content":"","date":null,"permalink":"https://puresecurity.com/hi/services/governance/cyber-crisis-tabletop-exercises/","section":"सुरक्षा सेवाएं","summary":"","title":"साइबर संकट प्रबंधन एवं कार्यकारी टेबलटॉप अभ्यास"},{"content":"","date":null,"permalink":"https://puresecurity.com/hi/services/technical/vulnerability-management/","section":"सुरक्षा सेवाएं","summary":"","title":"भेद्यता प्रबंधन एवं अनुपालन स्कैनिंग"},{"content":"","date":null,"permalink":"https://puresecurity.com/hi/services/technical/dfir-retainer/","section":"सुरक्षा सेवाएं","summary":"","title":"DFIR रिटेनर एवं आंतरिक जांच सेवा"},{"content":"","date":null,"permalink":"https://puresecurity.com/hi/categories/","section":"Categories","summary":"","title":"Categories"},{"content":"","date":null,"permalink":"https://puresecurity.com/hi/tags/incident-response/","section":"Tags","summary":"","title":"Incident Response"},{"content":"","date":null,"permalink":"https://puresecurity.com/hi/categories/insights/","section":"Categories","summary":"","title":"Insights"},{"content":"","date":null,"permalink":"https://puresecurity.com/hi/tags/","section":"Tags","summary":"","title":"Tags"},{"content":"","date":null,"permalink":"https://puresecurity.com/hi/tags/thailand/","section":"Tags","summary":"","title":"Thailand"},{"content":"कोई भी संगठन हैक होने की योजना नहीं बनाता। लेकिन जो संगठन सफलतापूर्वक उबरते हैं, उनमें एक बात समान होती है: उन्होंने ज़रूरत पड़ने से बहुत पहले डिजिटल साक्ष्य सुरक्षित कर लिए थे। जब कोई गंभीर घटना होती है (जैसे रैनसमवेयर, अंदरूनी डेटा चोरी या एडमिन अकाउंट में सेंध), तो दो सप्ताह में उबरने और दो महीने के कानूनी संकट के बीच का अंतर शांत समय में लिए गए निर्णयों से तय होता है।\nडिजिटल फोरेंसिक और इंसिडेंट रिस्पांस (DFIR) तत्परता वह अनुशासन है जो उन निर्णयों को समय से पहले लेना सुनिश्चित करता है।\nफोरेंसिक जांच हमले से पहले शुरू होती है #फोरेंसिक का पहला नियम है: आप उसकी जांच नहीं कर सकते जिसे आपने पहले रिकॉर्ड नहीं किया। जब तक किसी घटना का पता चलता है, यदि सिस्टम को पहले से कॉन्फ़िगर नहीं किया गया है तो मेमोरी (RAM), सिस्टम लॉग और नेटवर्क कैप्चर जैसे साक्ष्य मिट चुके होते हैं।\nडिजिटल साक्ष्य संग्रह पर RFC 3227 स्पष्ट करता है कि तत्परता का अर्थ है:\nकेंद्रीकृत ऑफ-होस्ट लॉगिंग: ताकि सर्वर से समझौता करने वाला हमलावर अपने निशान न मिटा सके। नियामक अनुरूप लॉग संरक्षण: थाई PDPA और बैंक ऑफ थाईलैंड के दिशानिर्देशों के अनुसार लॉग्स का भंडारण। समय तुल्यकालन (NTP): सभी सिस्टम्स में सटीक टाइमलाइन विश्लेषण के लिए आवश्यक। साक्ष्य की श्रृंखला (Chain of Custody): यह सुनिश्चित करना कि एकत्रित साक्ष्य अदालतों और नियामकों के समक्ष कानूनी रूप से मान्य हों। आंतरिक IT टीम को बाहरी विशेषज्ञ सहायता की आवश्यकता क्यों है #संकट के समय आपकी आंतरिक टीम को सिस्टम रीस्टोर करने और प्रबंधन को रिपोर्ट करने पर ध्यान देना होता है। फोरेंसिक एक अलग विशेषज्ञता है जिसके लिए विशेष कौशल की आवश्यकता होती है।\nएक DFIR रिटेनर कानूनी रूप से मान्य साक्ष्य प्रबंधन के साथ एक त्वरित प्रतिक्रिया टीम प्रदान करता है, जिससे आपकी टीम सिस्टम बहाली पर ध्यान केंद्रित कर सकती है।\nगति एक व्यावसायिक मीट्रिक है # MTTD (औसत पहचान समय): हमले का पता चलने से पहले हमलावर कितने समय तक सक्रिय रहा। MTTR (औसत प्रतिक्रिया समय): घटना की पहचान से लेकर रोकथाम और सिस्टम बहाली तक का समय। NIST SP 800-61 पूरे घटना प्रतिक्रिया जीवनचक्र को इन दोनों नंबरों को कम करने पर केंद्रित करता है।\nflowchart LR A[पहचान] --\u003e B[रोकथाम] B --\u003e C[उन्मूलन] C --\u003e D[पुनर्प्राप्ति] D --\u003e E[सबक और सुधार] E --\u003e|फीडबैक| A style A stroke:#0EA5E9,stroke-width:2px style E stroke:#10B981,stroke-width:2px थाईलैंड में विनियामक वास्तविकताएं #थाईलैंड का PDPA कानून डेटा उल्लंघन की त्वरित सूचना देने का आदेश देता है। साक्ष्यों के बिना दी गई गलत या अधूरी सूचना सुरक्षा विफलता को एक बड़े कानूनी उल्लंघन में बदल देती है।\nयदि आज कोई घटना घटित होती है, तो क्या आपकी टीम तैयार है? तकनीकी चर्चा के लिए संपर्क करें: ईमेल (hello@puresecurity.com) या LINE (@PureSecurity)। हमारा DFIR रिटेनर और आंतरिक जांच गारंटीकृत SLA के साथ विशेषज्ञ प्रतिक्रिया प्रदान करता है, और हमारे साइबर क्राइसिस टेबलटॉप अभ्यास संकट से पहले आपकी योजना का परीक्षण करते हैं।\n","date":"11 अगस्त 2026","permalink":"https://puresecurity.com/hi/posts/dfir-readiness-incident-response-thailand/","section":"सुरक्षा विश्लेषण एवं तकनीकी सलाह","summary":"","title":"थाईलैंड में डिजिटल फोरेंसिक और IR तत्परता"},{"content":"","date":null,"permalink":"https://puresecurity.com/hi/","section":"सीआईएसओ नेतृत्व वाली सुरक्षा एवं शासन","summary":"","title":"सीआईएसओ नेतृत्व वाली सुरक्षा एवं शासन"},{"content":"हमारे सुरक्षा इंजीनियरों और सीआईएसओ द्वारा लिखे गए तकनीकी विश्लेषण और व्यावहारिक लेख। प्रत्येक लेख में वास्तविक ऑडिट निष्कर्षों, नियंत्रण प्रभावशीलता और अनुशंसित तकनीकी समाधानों का स्पष्ट विवरण दिया गया है।\n","date":null,"permalink":"https://puresecurity.com/hi/posts/","section":"सुरक्षा विश्लेषण एवं तकनीकी सलाह","summary":"","title":"सुरक्षा विश्लेषण एवं तकनीकी सलाह"},{"content":"","date":null,"permalink":"https://puresecurity.com/hi/tags/apac/","section":"Tags","summary":"","title":"APAC"},{"content":"Modern organisation single company नहीं है; वह vendors, SaaS platforms, cloud providers और integrators का web है, और हर एक आपके data और reputation का एक thread hold करता है। इनमें से कोई fail होता है तो उसकी failure आप inherit करते हैं: regulator आपसे पूछता है कि vendor vetted क्यों था, और customer आपसे पूछता है कि उसका data आपके chosen supplier से leak क्यों हुआ।\nThird-party risk management (TPRM) उस web को legible बनाने का discipline है: यह जानना कि किसे किस चीज़ तक access है, आप उन पर कितना depend करते हैं, और उनके controls actually hold up करते हैं या नहीं।\nQuestionnaire का trap #ज़्यादातर TPRM programmes 200-500 questions की spreadsheet होती हैं जो हर vendor को भेजी जाती है, file कर दी जाती है और annually भूला दी जाती है। इससे paperwork produce होता है पर risk reduction बहुत कम, two reasons:\nयह हर vendor को equally treat करता है। Coffee supplier और payments processor को same questionnaire मिलती है, जबकि exposure wildly different है। यह self-attestation trust करता है। \u0026ldquo;Yes, we encrypt data\u0026rdquo; कहने वाला vendor वह नहीं है जो यह दिखा सके। Questionnaires confidence measure करते हैं, controls नहीं। Fix proportionality और verification है। Vendors को actual access के हिसाब से categorise करें, फिर deep-dive effort वहां spend करें जहां exposure real है।\nActual exposure से tiering #Workable model vendors को उसके हिसाब से tier करता है कि वे क्या touch करते हैं:\nTier 1, critical: cardholder या personal data hold करते हैं, आपके systems से deeply integrate होते हैं, या single point of failure हैं। इन्हें technical assessment, audit rights और contractual security schedules मिलती हैं। Tier 2, significant: business data process करते हैं या privileged access रखते हैं। इन्हें lighter technical review और periodic re-validation मिलती है। Tier 3, transactional: limited या no data access। इन्हें baseline due diligence मिलती है, उससे ज्यादा कुछ नहीं। Point more process नहीं है; proportionate process है। Tier 1 payment gateway fail हुई तो incident है। Tier 3 stationery vendor fail हुआ तो inconvenience है। दोनों को same treat करना wrong risk पर effort waste कराता है।\nflowchart TD A[New vendor] --\u003e B{Data and access level?} B --\u003e|Critical| C[Tier 1: deep technical review] B --\u003e|Significant| D[Tier 2: lighter review] B --\u003e|Transactional| E[Tier 3: baseline diligence] C --\u003e F[Contractual security schedule + audit rights] style C stroke:#F43F5E,stroke-width:2px style F stroke:#10B981,stroke-width:2px Questionnaire के beyond: technical verification #उन vendors के लिए जो matter करते हैं, self-attestation enough नहीं है। Technical verification का मतलब है evidence मांगना, और जहां relationship justify करे तो testing:\nEvidence review: SOC 2 reports, ISO 27001 certificates, PCI DSS AOCs, और critically उन reports का scope, सिर्फ logo नहीं। Architecture review: vendor अपने environment में आपका data actually कैसे handle करता है, marketing page कैसे describe नहीं करता। Contractual teeth: enforceable security schedules, breach-notification timelines, और audit rights जो renegotiation survive करें। Frameworks इस पर agree करते हैं। NIST SP 800-161 supply chain risk पर, और ISO 27001 के supplier security clauses (2022 edition mapping में A.15), दोनों blanket questionnaires की जगह proportionate, evidence-based vendor assurance push करते हैं। Bank of Thailand outsourcing guidance financial institutions और उनके critical vendors पर same logic apply करती है।\nContinuous, one-off नहीं #Vendor risk static नहीं रहता। पिछले साल review pass करने वाला vendor इस साल acquired, breached, या quietly sub-processors change कर सकता है। Mature model risk-based cycle पर re-validate करता है, signals monitor करता है (data breaches, ownership changes, certificate lapses), और offboarding path रखता है जो access actually revoke करता है, invoice cancel करना सिर्फ नहीं।\nVendor questionnaires के burden से buried feel करते हैं जो risk reduce कभी नहीं करते? सीधी समझ-जांच के लिए संपर्क करें: LINE (@PureSecurity) या email (hello@puresecurity.com). हमारा Third-Party Risk Management tiering model build करता है, deep-dive reviews run करता है, और contractual security schedules draft करता है जो आपकी legal team needs। इसे Regulatory Compliance के साथ pair करें vendor obligations को BOT और ISO 27001 requirements map करने के लिए।\n","date":"15 जुलाई 2026","permalink":"https://puresecurity.com/hi/posts/third-party-risk-management-apac/","section":"सुरक्षा विश्लेषण एवं तकनीकी सलाह","summary":"","title":"APAC एंटरप्राइज के लिए थर्ड-पार्टी रिस्क मैनेजमेंट"},{"content":"","date":null,"permalink":"https://puresecurity.com/hi/tags/governance--leadership/","section":"Tags","summary":"","title":"Governance \u0026 Leadership"},{"content":"","date":null,"permalink":"https://puresecurity.com/hi/tags/third-party-risk/","section":"Tags","summary":"","title":"Third-Party Risk"},{"content":"उत्पादन में अधिकांश लिनक्स सिस्टम अपने डिफ़ॉल्ट कॉन्फ़िगरेशन के बहुत करीब चलते हैं, जितना कि कोई भी स्वीकार करना चाहेगा। हार्डनिंग दस्तावेज़ किसी पुरानी ऑडिट फ़ाइल में मौजूद होते हैं, लेकिन वास्तविक सर्वर उनसे मेल नहीं खाते। \u0026ldquo;दस्तावेजी बेसलाइन\u0026rdquo; और \u0026ldquo;वास्तविक कॉन्फ़िगरेशन\u0026rdquo; के बीच का यह अंतर वही स्थान है जहाँ हमलावर आसानी से अपनी जगह बना लेते हैं।\nलिनक्स हार्डनिंग उस अंतर को बंद करने का इंजीनियरिंग अनुशासन है, और इसे इस तरह से करना है जो अगले डिप्लॉयमेंट के बाद भी टिका रहे।\nडिफ़ॉल्ट सेटिंग्स संगतता को प्राथमिकता देती हैं, सुरक्षा को नहीं #एक डिफ़ॉल्ट लिनक्स इंस्टॉलेशन सुरक्षा को नहीं, बल्कि संगतता को प्राथमिकता देता है। यह उन सेवाओं के साथ आता है जिनका आप उपयोग नहीं करते, उन कर्नेल सुविधाओं के साथ जिनकी आपको आवश्यकता नहीं है, और ऐसी लॉगिंग के साथ जो डेस्कटॉप के लिए पर्याप्त है लेकिन किसी खतरे में पड़े उत्पादन सर्वर के लिए नहीं। हार्डनिंग उस सामान्य प्रयोजन मशीन को एक विशेष रूप से सुरक्षित प्रणाली में बदलने की प्रक्रिया है।\nमुख्य कार्य कुछ प्रमुख श्रेणियों में आता है:\nकर्नेल और sysctl ट्यूनिंग: नेटवर्क सुरक्षा (जैसे ICMP रीडायरेक्ट्स को अनदेखा करना, रिवर्स-पाथ फ़िल्टरिंग सक्षम करना), फ़ाइल सिस्टम प्रतिबंध, और ASLR (एड्रेस स्पेस लेआउट रैंडमाइजेशन) जैसी मेमोरी सुरक्षा। सेवाओं का न्यूनीकरण: उन सभी सेवाओं और पैकेजों को अक्षम और हटाना जिन्हें होस्ट नहीं चलाता, ताकि शोषण के लिए कोई अप्रयुक्त घटक न बचे। अनिवार्य एक्सेस कंट्रोल (MAC): किसी प्रक्रिया द्वारा क्या किया जा सकता है इसे सीमित करने के लिए SELinux या AppArmor, भले ही वह प्रक्रिया प्रभावित क्यों न हो गई हो। Systemd और कंटेनर हार्डनिंग: लिनक्स क्षमताओं (capabilities) को छोड़ना, रॉ सॉकेट एक्सेस को ब्लॉक करना, और seccomp प्रोफाइल के साथ सिस्टम कॉल को प्रतिबंधित करना। ऑडिट और लॉगिंग: महत्वपूर्ण घटनाओं को कैप्चर करना और उन्हें होस्ट से बाहर केंद्रीय सर्वर पर भेजना ताकि हमलावर अपने पैरों के निशान न मिटा सके। CIS बेंचमार्क (CIS Benchmarks) इन नियंत्रणों के सबसे व्यावहारिक और व्यापक रूप से मान्यता प्राप्त मानक बने हुए हैं, और OpenSCAP इन्हें लागू करने और ऑडिट करने दोनों को स्वचालित करता है।\nकॉन्फ़िगरेशन कोड के रूप में है, अन्यथा इसका कोई अस्तित्व नहीं है #विकी पर मौजूद हार्डनिंग गाइड केवल एक इच्छा सूची है। कोड में मौजूद हार्डनिंग (जैसे Ansible रोल, Packer इमेज, Kubernetes एडमिशन पॉलिसी) एक ठोस वास्तविकता है। जब बेसलाइन कोड होती है, तो तीन चीजें बदल जाती हैं:\nयह पुनरुत्पादन योग्य (reproducible) है। प्रत्येक नया होस्ट बेसलाइन विरासत में प्राप्त करता है, न कि केवल वही जिन्हें कोई कॉन्फ़िगर करना याद रखता है। यह परीक्षण योग्य है। CI/CD में एक अनुपालन स्कैन बिल्ड को विफल कर देता है जब कोई सेटिंग विचलित होती है। यह समीक्षा योग्य है। बेसलाइन में बदलाव एक पुल रिक्वेस्ट (Pull Request) होता है, जिसमें एप्लिकेशन कोड के समान समीक्षा अनुशासन होता है। यह वार्षिक औपचारिकता के रूप में हार्डनिंग और प्लेटफ़ॉर्म की एक स्थायी विशेषता के रूप में हार्डनिंग के बीच का वास्तविक अंतर है।\nअंतिम लक्ष्य: अपरिवर्तनीय इन्फ्रास्ट्रक्चर (Immutable Infrastructure) #तार्किक निष्कर्ष अपरिवर्तनीय इन्फ्रास्ट्रक्चर है: होस्ट और कंटेनर को कभी भी सीधे पैच नहीं किया जाता, केवल बदला जाता है। एक नई इमेज बनाई जाती है, स्कैन की जाती है और तैनात की जाती है; पुरानी इमेज को नष्ट कर दिया जाता है। कॉन्फ़िगरेशन ड्रिफ्ट असंभव हो जाता है क्योंकि ड्रिफ्ट होने के लिए कुछ भी नहीं बचता: चालू सिस्टम एक बिल्ड आर्टिफैक्ट होता है।\nअपरिवर्तनीय इन्फ्रास्ट्रक्चर स्वाभाविक रूप से हार्डनिंग-ऐज़-कोड के साथ जुड़ता है। आप किसी बेसलाइन का रखरखाव नहीं कर रहे हैं; आप इमेज में ही सुरक्षा को संकलित कर रहे हैं। और जब कोई भेद्यता सामने आती है, तो समाधान आधी रात का SSH सत्र नहीं बल्कि एक नया रीबिल्ड होता है।\nflowchart LR A[CIS बेंचमार्क कोड के रूप में] --\u003e B[CI में हार्डन इमेज बिल्ड] B --\u003e C[पाइपलाइन में अनुपालन स्कैन] C -- पास --\u003e D[तैनाती और इंस्टेंस रोटेशन] C -- फेल --\u003e B style C stroke:#0EA5E9,stroke-width:2px style D stroke:#10B981,stroke-width:2px होस्ट से आगे #हार्डनिंग ऑपरेटिंग सिस्टम पर समाप्त नहीं होती। वही अनुशासन कई दिशाओं में बाहर की ओर फैलता है, जिनमें से प्रत्येक के अपने विफलता मोड होते हैं।\nकंटेनर सब कुछ विरासत में लेते हैं, फिर अपने जोखिम जोड़ते हैं। एक गैर-हार्डन बेस लेयर से निर्मित कंटेनर इमेज हर होस्ट-स्तरीय कमजोरी को चलाने वाले प्रत्येक पॉड में ले जाती है। समाधान अपस्ट्रीम है: न्यूनतम बेस इमेज, CI में स्कैन की गई, गैर-रूट और रीड-ओनली फ़ाइल सिस्टम के साथ चलने वाली, हटाई गई क्षमताएं, और सेडकम्प प्रोफाइल जो वर्कलोड को आवश्यक सिस्टम कॉल तक सीमित करती हैं। डिफ़ॉल्ट सेडकम्प प्रोफ़ाइल बहुत कुछ ब्लॉक करती है; कार्यभार व्यवहार के अनुसार ट्यून की गई एक प्रोफ़ाइल बाकी सब कुछ ब्लॉक कर देती है। कुबेरनेट्स एडमिशन नीतियां पूरे बेड़े में इसे लागू करती हैं, इसलिए गैर-अनुपालन परिनियोजन कभी शेड्यूल ही नहीं होता।\nOT वातावरण दांव बढ़ा देते हैं। औद्योगिक और परिचालन प्रौद्योगिकी (OT) सेटिंग्स में, हार्डनिंग उपलब्धता से इस तरह टकराती है जो सामान्य आईटी कभी नहीं देखती। बिल्डिंग मैनेजमेंट सिस्टम, प्रोडक्शन लाइन पीएलसी नेटवर्क या अस्पताल डिवाइस सेगमेंट पर गलत तरीके से लागू किया गया सीआईएस नियंत्रण केवल एक निष्कर्ष नहीं देता: यह डाउनटाइम पैदा करता है, कभी-कभी सुरक्षा परिणामों के साथ। इसलिए ओटी हार्डनिंग सामान्य क्रम को उलट देती है: निष्क्रिय निगरानी और इन्वेंट्री पहले आती है, परिवर्तन रोलबैक योजनाओं के साथ रखरखाव विंडो में होते हैं, और वास्तविक सिस्टम को छूने से पहले उत्पादन के दर्पण पर नियंत्रणों का परीक्षण किया जाता है। जहाँ आईटी पूछता है \u0026ldquo;क्या यह सिस्टम सुरक्षित है?\u0026rdquo;, ओटी को पूछना चाहिए \u0026ldquo;क्या हम इसे रोके बिना सुरक्षित कर सकते हैं?\u0026rdquo;\nड्रिफ्ट डिटेक्शन चक्र को पूरा करता है। नियमित परिवर्तनों के माध्यम से बेसलाइन खराब हो जाती है: एक इंजीनियर डिबग करने के लिए पोर्ट खोलता है, एक इंस्टॉलर सेवा को पुनः सक्षम करता है, एक हॉटफिक्स कभी कोड में वापस नहीं आता। पहचान के बिना, आज का हार्डन होस्ट अगले साल की कमजोरी बन जाता है। जो पैटर्न काम करता है: कोडित बेसलाइन के खिलाफ लाइव होस्ट और छवियों की तुलना करने वाले दैनिक कार्यक्रम पर कॉन्फ़िगरेशन स्कैनिंग, जिसमें निष्कर्षों को त्रैमासिक रिपोर्ट में दर्ज करने के बजाय स्वामियों को अलर्ट के रूप में भेजा जाता है। एक दिन के भीतर पाया गया विचलन एक टिकट है; एक साल बाद पाया गया विचलन एक सुरक्षा घटना की जांच है।\nअत्यधिक अनुमेय क्लाउड IAM भूमिका के पीछे, या बिना स्कैन की गई कंटेनर पाइपलाइन के अंदर एक हार्डन होस्ट अभी भी असुरक्षित है। एक टिकाऊ सुरक्षा स्थिति होस्ट बेसलाइन, कंटेनर बिल्ड चेन, क्लाउड कॉन्फ़िगरेशन और पहचान सीमाओं को एक सतत सतह के रूप में मानती है, और उसी के अनुसार निगरानी करती है।\nनिश्चित नहीं हैं कि आपके सर्वर वास्तव में आपके हार्डनिंग दस्तावेज़ों से मेल खाते हैं या नहीं? सीधी तकनीकी समीक्षा के लिए संपर्क करें: ईमेल (hello@puresecurity.com) या LINE (@PureSecurity)। हमारी लिनक्स एवं इंफ्रास्ट्रक्चर हार्डनिंग सेवा कोड के रूप में बेसलाइन और स्वचालित ड्रिफ्ट डिटेक्शन प्रदान करती है, और हमारा कॉन्फ़िगरेशन एवं आर्किटेक्चर मूल्यांकन होस्ट के आसपास क्लाउड और पहचान परत की समीक्षा करता है। पूरी जानकारी के लिए इंजीनियरिंग एवं स्कोपिंग सत्र निर्धारित करें।\n","date":"17 जून 2026","permalink":"https://puresecurity.com/hi/posts/linux-infrastructure-hardening-apac/","section":"सुरक्षा विश्लेषण एवं तकनीकी सलाह","summary":"","title":"APAC प्रणालियों के लिए लिनक्स इन्फ्रास्ट्रक्चर हार्डनिंग"},{"content":"","date":null,"permalink":"https://puresecurity.com/hi/tags/security-engineering/","section":"Tags","summary":"","title":"Security Engineering"},{"content":"","date":null,"permalink":"https://puresecurity.com/hi/tags/compliance--regulatory/","section":"Tags","summary":"","title":"Compliance \u0026 Regulatory"},{"content":"","date":null,"permalink":"https://puresecurity.com/hi/tags/data-protection/","section":"Tags","summary":"","title":"Data Protection"},{"content":"","date":null,"permalink":"https://puresecurity.com/hi/tags/penetration-testing/","section":"Tags","summary":"","title":"Penetration Testing"},{"content":"वर्षों से \u0026ldquo;पारगमन में डेटा को एन्क्रिप्ट करने\u0026rdquo; का एक ही अर्थ था: HTTPS लागू करना। लोड बैलेंसर पर TLS समाप्त हो जाता था, पेलोड आंतरिक नेटवर्क में प्लेनटेक्स्ट के रूप में प्रवाहित होता था, और सभी इसे एन्क्रिप्टेड मानते थे। बैंक ऑफ थाईलैंड (BOT) इस अंतर को लगातार समाप्त कर रहा है: संवेदनशील वित्तीय डेटा के लिए, केवल ट्रांसपोर्ट एन्क्रिप्शन अब पर्याप्त नहीं है।\nट्रांसपोर्ट और पेलोड एन्क्रिप्शन के बीच अंतर #TLS केवल नेटवर्क तार पर दो बिंदुओं के बीच डेटा की सुरक्षा करता है। यह एप्लिकेशन आर्किटेक्चर के भीतर डेटा की सुरक्षा नहीं करता। जिस क्षण TLS रिवर्स प्रॉक्सी या API गेटवे पर समाप्त होता है, अनुरोध का मुख्य भाग डिक्रिप्ट हो जाता है और प्लेनटेक्स्ट बन जाता है।\nयह प्लेनटेक्स्ट उन स्थानों पर चला जाता है जहाँ इसे नहीं होना चाहिए:\nलॉग फ़ाइलें: गेटवे पूरे रिक्वेस्ट बॉडी को लॉग कर लेते हैं, जिससे बैंक खाते और कार्ड नंबर रिकॉर्ड हो जाते हैं। सर्विस मेश और आंतरिक हॉप्स: माइक्रोसर्विसेज के बीच का आंतरिक ट्रैफ़िक अक्सर यह मानकर अनएन्क्रिप्टेड छोड़ दिया जाता है कि आंतरिक नेटवर्क सुरक्षित है। मेमोरी और कैश: इन-मेमोरी ऑब्जेक्ट्स और APM ट्रेस में संवेदनशील डेटा प्लेनटेक्स्ट में रह जाता है। ऑब्जर्वेबिलिटी पाइपलाइन: ट्रेसिंग टूल्स इस डेटा को विभिन्न टीमों और बाहरी थर्ड पार्टी टूल्स में भेजते हैं। एप्लिकेशन-लेयर पेलोड एन्क्रिप्शन संदेश को स्वयं एन्क्रिप्ट करके इस अंतर को बंद करता है।\nflowchart LR A[क्लाइंट] --\u003e|TLS| B[API गेटवे: TLS समाप्त] B --\u003e|प्लेनटेक्स्ट| C[बैकएंड सेवा] C --\u003e|प्लेनटेक्स्ट| D[लॉग / ट्रेस / कैश] subgraph \"एप्लिकेशन-लेयर एन्क्रिप्शन\" E[एन्क्रिप्टेड पेलोड] -.-\u003e|JWE / AES-GCM| B B -.-\u003e E2[आंतरिक रूप से भी एन्क्रिप्टेड] end style D stroke:#F43F5E,stroke-width:2px style E2 stroke:#10B981,stroke-width:2px उपयोग किए जाने वाले मानक # JSON Web Encryption (JWE) (RFC 7516): संरचित API पेलोड को एन्क्रिप्ट करने का प्रमुख मानक। AES-256-GCM: पेलोड बॉडी के लिए प्रमाणित सममित एन्क्रिप्शन, जो गोपनीयता और अखंडता दोनों प्रदान करता है। RSA-OAEP या ECDH: असममित कुंजी एक्सचेंज जो पारगमन और भंडारण में सममित कुंजी की सुरक्षा करता है। बैंक ऑफ थाईलैंड इसे क्यों अनिवार्य कर रहा है #थाईलैंड के पूरे भुगतान तंत्र में वित्तीय APIs मुख्य आधार बन चुकी हैं। गेटवे के एक गलत कॉन्फ़िगरेशन से लॉग एक्सेस वाले किसी भी व्यक्ति को संवेदनशील डेटा नहीं मिलना चाहिए। पेलोड एन्क्रिप्शन रक्षा-गहन (Defense-in-Depth) रणनीति का हिस्सा है।\nइंजीनियरिंग टीमों के लिए व्यावहारिक निहितार्थ # कुंजी प्रबंधन (Key Management): रोटेशन, हस्ताक्षर और एन्क्रिप्शन कुंजियों का पृथक्करण, और HSM/KMS सुरक्षित भंडारण। गेटवे और लॉगिंग में बदलाव: मिडलवेयर अब सीधे पेलोड को नहीं पढ़ सकता। अनुबंध और समन्वय: डाउनस्ट्रीम उपभोक्ताओं को डिक्रिप्ट करने में सक्षम होना चाहिए, जिसके लिए मजबूत कुंजी वितरण की आवश्यकता होती है। परीक्षण: observability को \u0026ldquo;पेलोड dump करो\u0026rdquo; से \u0026ldquo;authenticate और authorize करो, फिर केवल आवश्यकतानुसार decrypt करो\u0026rdquo; में बदलना होगा। क्या आपकी वित्तीय APIs बैंक ऑफ थाईलैंड की अपेक्षाओं को पूरा करती हैं? तकनीकी समीक्षा के लिए संपर्क करें: ईमेल (hello@puresecurity.com) या LINE (@PureSecurity)। हमारी API और एप्लिकेशन सुरक्षा समीक्षा आपके पेलोड की एंड-टू-एंड सुरक्षा को सत्यापित करती है, और हमारी विनियामक अनुपालन सेवा BOT दिशानिर्देशों को पूरा करने में मदद करती है।\n","date":"13 मई 2026","permalink":"https://puresecurity.com/hi/posts/bot-api-payload-encryption-thailand/","section":"सुरक्षा विश्लेषण एवं तकनीकी सलाह","summary":"","title":"बैंक ऑफ थाईलैंड API पेलोड एन्क्रिप्शन नियम"},{"content":"प्रत्येक संगठन के पास एक घटना प्रतिक्रिया योजना (Incident Response Plan) होती है। लेकिन उनमें से अधिकांश का वास्तव में कभी परीक्षण नहीं किया गया है। योजना केवल फाइलों में रहती है और समय के दबाव में वास्तविक निर्णय लेने के संपर्क में कभी नहीं आई होती। पहली बार जब इसे लागू किया जाता है तो वह वास्तविक संकट का समय होता है, और ठीक उसी समय अप्रशिक्षित योजनाएं विफल हो जाती हैं।\nएक टेबलटॉप अभ्यास इसे किफायती और प्रभावी ढंग से ठीक करता है: एक निर्देशित, परिणाम-आधारित साइबर संकट सिमुलेशन, जो आपके वास्तविक नेतृत्व, आपकी वास्तविक सीमाओं और आपके वास्तविक नियामकों के संदर्भ में आयोजित किया जाता है।\nपहली बार में योजनाएं क्यों विफल हो जाती हैं #वास्तविक घटनाएं सीधी नहीं होती हैं। वे अस्पष्ट, शोरगुल वाली और ऐसे निर्णयों से भरी होती हैं जिन्हें कोई हैंडबुक पहले से पूरी तरह से तय नहीं कर सकती:\nहम बोर्ड को कब सूचित करते हैं? बहुत जल्दी, तो आप अनावश्यक घबराहट पैदा करते हैं; बहुत देर से, तो आप उनका विश्वास खो देते हैं। हम नियामक को कब सूचित करते हैं? थाईलैंड में, बैंक ऑफ थाईलैंड और अन्य नियामक उल्लंघनों की रिपोर्टिंग के लिए सख्त समयसीमा लागू करते हैं। ग्राहकों से कौन बात करता है और किन शब्दों में? गलत तरीके से दिया गया पहला बयान तकनीकी समस्या की तुलना में प्रतिष्ठा को अधिक नुकसान पहुंचाता है। उत्पादन प्रणालियों को बंद करने के लिए कौन अधिकृत है? एक वास्तविक संकट में, निर्णय लेने के अधिकार वाला व्यक्ति अक्सर तकनीकी विवरण जानने वाला व्यक्ति नहीं होता है। ये निर्णय लोगों द्वारा लिए जाते हैं, प्रक्रियाओं द्वारा नहीं। एक टेबलटॉप अभ्यास यह उजागर करता है कि आपके निर्णय कहाँ रुकते हैं, हमलावर द्वारा शोषण किए जाने से बहुत पहले।\nएक प्रभावी संकट अभ्यास कैसा होता है #एक अच्छी तरह से डिज़ाइन किया गया टेबलटॉप अभ्यास वास्तविक खतरों पर आधारित होता है और आपके उद्योग के अनुरूप होता है। यह एक यथार्थवादी हमले की श्रृंखला का अनुकरण करता है, जैसे एक आपूर्ति श्रृंखला समझौता जो विक्रेता अलर्ट से शुरू होता है और महत्वपूर्ण प्रणालियों पर रैनसमवेयर में बदल जाता है।\nमुख्य मूल्य बाद की समीक्षा (Debriefing) में है:\nनिर्णय की गति: पहचान से लेकर ठोस कार्यकारी निर्णय तक कितना समय लगा? एस्केलेशन स्पष्टता: क्या सभी को पता था कि अंतिम निर्णय का अधिकार किसके पास है? नियामक सटीकता: क्या आपकी विनियामक सूचनाएं समय पर और नियमों के अनुरूप थीं? संचार निरंतरता: क्या आंतरिक स्थिति और बाहरी सार्वजनिक संदेश मेल खाते थे? NIST SP 800-84 इसे किसी भी अभ्यास कार्यक्रम का मूल सिद्धांत मानता है: अभ्यास कमियों को उजागर करने और सुधारने के लिए होते हैं।\nवह पैटर्न जिसे अधिकांश टीमें अनदेखा कर देती हैं #लगभग हर अभ्यास में सबसे बड़ा निष्कर्ष तकनीकी नहीं होता। वह यह होता है कि तकनीकी टीम और कार्यकारी नेतृत्व एक ही घटना के बिल्कुल अलग मानसिक मॉडल पर काम करते हैं। इंजीनियर रोकथाम और मूल कारण पर ध्यान केंद्रित करते हैं; अधिकारी कानूनी देयता और ग्राहक विश्वास के बारे में सोचते हैं। यदि वे पहली बार वास्तविक संकट के दौरान मिलते हैं, तो घर्षण गलत समय पर होता है।\nएक टेबलटॉप अभ्यास उस घर्षण को एक सुरक्षित कमरे में सबक में बदल देता है।\nआपकी घटना प्रतिक्रिया योजना का वास्तव में आखिरी बार कब परीक्षण किया गया था? संपर्क करें: ईमेल (hello@puresecurity.com) या LINE (@PureSecurity)। हमारे साइबर क्राइसिस टेबलटॉप अभ्यास आपके बुनियादी ढांचे और नियामक वातावरण के अनुरूप आधे दिन के सिमुलेशन हैं, जो बोर्ड के लिए एक रेडीनेस रिपोर्ट प्रदान करते हैं। इसे हमारे DFIR रिटेनर के साथ जोड़ें ताकि संकट के समय आपको सुधारने के लिए संघर्ष न करना पड़े।\n","date":"15 अप्रैल 2026","permalink":"https://puresecurity.com/hi/posts/cyber-crisis-tabletop-apac/","section":"सुरक्षा विश्लेषण एवं तकनीकी सलाह","summary":"","title":"APAC कंपनियों के लिए साइबर क्राइसिस टेबलटॉप अभ्यास"},{"content":"अधिकांश एप्लिकेशन वर्षों पहले केवल \u0026ldquo;वेबसाइट\u0026rdquo; रहना बंद कर चुके हैं। आज वे APIs के रूप में कार्य करते हैं: माइक्रोसर्विसेज एक-दूसरे को कॉल करती हैं, एक छोर पर मोबाइल क्लाइंट और दूसरे छोर पर पेमेंट गेटवे होते हैं। लेकिन सुरक्षा ऑडिट अक्सर इस बदलाव के साथ तालमेल नहीं बिठा पाते। टीमें अभी भी पारंपरिक \u0026ldquo;वेब एप्लिकेशन पेनेट्रेशन टेस्ट\u0026rdquo; खरीदती हैं जो 80% प्रयास फ्रंट-एंड पर खर्च करते हैं, जबकि पीछे स्थित APIs, जहां वास्तव में वित्तीय डेटा और संवेदनशील जानकारी प्रवाहित होती है, का पर्याप्त परीक्षण नहीं हो पाता।\nस्वचालित स्कैनर APIs पर विफल क्यों होते हैं #स्वचालित वेब स्कैनर पारंपरिक वेबपेज मॉडल के आधार पर तैयार किए गए हैं: लिंक्स को क्रॉल करना, फॉर्म ढूंढना और पेलोड इंजेक्ट करना। लेकिन APIs वेबपेज प्रस्तुत नहीं करते। वे रूट्स, HTTP मेथड्स और संरचित स्कीमा प्रस्तुत करते हैं, और सबसे संवेदनशील व्यवहार उनके बीच के बिजनेस लॉजिक में होता है।\nऑब्जेक्ट-लेवल एक्सेस दोष पर विचार करें: एक प्रमाणित उपयोगकर्ता रिक्वेस्ट में user_id=1024 को बदलकर user_id=1025 कर देता है और किसी अन्य ग्राहक के गोपनीय रिकॉर्ड देख लेता है। कोई सुरक्षा सिग्नेचर ट्रिगर नहीं होता। पेलोड में कोई दुर्भावनापूर्ण कोड नहीं होता। स्कैनर एक सामान्य HTTP 200 प्रतिक्रिया देखता है और आगे बढ़ जाता है। इसे ब्रोकन ऑब्जेक्ट लेवल ऑथराइजेशन (BOLA) कहा जाता है, जो OWASP API Security Top 10 में नंबर एक पर है, और यह लगभग हर स्वचालित टूल के लिए अदृश्य है।\nयही कारण है कि मानव-विशेषज्ञों द्वारा संचालित API परीक्षण अपरिहार्य है: सबसे विनाशकारी खामियां डिज़ाइन और लॉजिक दोष होती हैं, और डिज़ाइन दोषों को खोजने के लिए ऐसे विश्लेषक की आवश्यकता होती है जो व्यावसायिक संदर्भ को समझता हो।\nएक प्रभावी API परीक्षण वास्तव में क्या कवर करता है #एक संपूर्ण और गंभीर API मूल्यांकन केवल OpenAPI विनिर्देश के विरुद्ध स्कैनर चलाने से कहीं आगे जाता है:\nप्रमाणीकरण और प्राधिकरण (AuthN \u0026amp; AuthZ): JWT टोकन प्रबंधन, स्कोप सत्यापन और प्रत्येक भूमिका सीमा पर ऑब्जेक्ट-स्तरीय एक्सेस नियंत्रण। बिजनेस लॉजिक: परीक्षण कि क्या उपयोगकर्ता नकारात्मक मूल्य लागू कर सकते हैं, भुगतान कॉलबैक को फिर से चला सकते हैं, या अंतिम एंडपॉइंट को सीधे कॉल करके अनुमोदन चरणों को छोड़ सकते हैं। अत्यधिक डेटा प्रदर्शन (Excessive Data Exposure): ऐसे एंडपॉइंट्स की पहचान करना जो क्लाइंट द्वारा आवश्यक फ़ील्ड्स को फ़िल्टर करने के बजाय संपूर्ण डेटाबेस ऑब्जेक्ट वापस भेजते हैं। रेट लिमिटिंग और दुरुपयोग रोकथाम: ब्रूट-फोर्स, क्रेडेंशियल स्टफिंग और बड़े पैमाने पर डेटा चोरी को रोकने के लिए थ्रॉटलिंग का विश्लेषण। एकता सीमाएं (Integration Boundaries): वेबहुक, तृतीय-पक्ष कॉलबैक और मैसेज कतारें जहां अक्सर बिना क्रिप्टोग्राफ़िक सत्यापन के विश्वास मान लिया जाता है। इसीलिए सर्वोत्तम ऑडिट मैन्युअल आक्रामक तकनीकों को AI-सहायता प्राप्त फ़ज़िंग के साथ जोड़ते हैं: ऑटोमेशन कवरेज का विस्तार करता है जबकि विशेषज्ञ गंभीरता और व्यावसायिक प्रभाव का आकलन करते हैं।\nवार्षिक ऑडिट के बजाय निरंतर सुरक्षा #साल में एक बार किया जाने वाला पेन-टेस्ट उस सिस्टम का केवल एक तात्कालिक स्नैपशॉट होता है जो हर हफ्ते नया कोड तैनात करता है। जब तक रिपोर्ट तैयार होती है, एंडपॉइंट्स पहले ही बदल चुके होते हैं। आधुनिक दृष्टिकोण API सुरक्षा जांच को डिलीवरी पाइपलाइन में एकीकृत करता है:\nShift-Left: CI/CD में स्थिर कोड विश्लेषण (SAST) और स्कीमा सत्यापन। रिलीज़-आधारित समीक्षा: API की सतह में बदलाव होने पर लक्षित समीक्षा। वार्षिक गहन ऑडिट: ऑडिट ट्रेल्स और जटिल बिजनेस लॉजिक को सत्यापित करने के लिए मानव-विशेषज्ञों द्वारा पूर्ण मूल्यांकन। PCI DSS आवश्यकता 6 और आवश्यकता 11.4 कार्ड डेटा संभालने वाले संगठनों के लिए इस स्तर की कठोरता की मांग करते हैं, जैसा कि बैंक ऑफ थाईलैंड के डिजिटल चैनल सुरक्षा दिशानिर्देश भी अनिवार्य करते हैं।\nflowchart LR A[CI में स्कीमा और SAST] --\u003e B[रिलीज़-आधारित API समीक्षा] B --\u003e C[मानव-संचालित गहन ऑडिट] C --\u003e D[सुधार और पुनः परीक्षण] D --\u003e A style C stroke:#0EA5E9,stroke-width:2px style D stroke:#10B981,stroke-width:2px स्वचालित स्कैनर क्या नहीं देख सकते #यह स्पष्ट रूप से समझना आवश्यक है कि स्वचालन क्या छोड़ देता है, क्योंकि खामियां यादृच्छिक नहीं होतीं: वे ठीक वहीं केंद्रित होती हैं जहां मुख्य लेनदेन होते हैं।\nव्यवहार में BOLA. स्कैनर खोजे गए एंडपॉइंट्स और समझे गए मापदंडों का परीक्षण करता है। चालान API में: GET /invoices/8842 कॉलर का अपना इनवॉइस लौटाता है, इसलिए स्कैनर इसे सफल मानता है। लेकिन GET /invoices/8843, जो किसी अन्य ग्राहक का इनवॉइस है, भी उतनी ही आसानी से प्राप्त किया जा सकता है। कोई भी स्कैनर इसे नहीं समझ सकता, क्योंकि 8843 किसी और का है, यह जानने के लिए आपके व्यवसाय में स्वामित्व के अर्थ को समझना आवश्यक है।\nबिजनेस लॉजिक खामियां. स्कैनर केवल यह जांचते हैं कि अनुरोध विफल होते हैं या नहीं; लॉजिक दोष उन अनुरोधों में होते हैं जो सफल होते हैं जब उन्हें विफल होना चाहिए। वास्तविक ऑडिट उदाहरण: भुगतान सत्यापन से पहले छूट कूपन दो बार लागू करना; बिना दोबारा प्रमाणीकरण के खातों के बीच बैलेंस ट्रांसफर करना; या पहले से शिप किए गए ऑर्डर को रद्द करना क्योंकि एंडपॉइंट पूर्ति स्थिति की जांच नहीं करता। ये सभी HTTP 200 लौटाते हैं और बिना किसी त्रुटि संदेश के वित्तीय नुकसान पहुंचाते हैं।\nमाइक्रोसर्विसेज के बीच विश्वास की धारणाएं. एक आंतरिक सेवा अक्सर अन्य सेवाओं से आने वाले हेडर या टोकन पर आँख मूंदकर भरोसा करती है। जब कोई एज-सर्विस प्रभावित होती है, तो यह विश्वास हमलावर के लिए अंदरूनी मुख्य सेवाओं तक पहुंचने का माध्यम बन जाता है।\nक्या आप सुनिश्चित करना चाहते हैं कि आपकी APIs का तकनीकी रूप से कठोर मूल्यांकन हुआ है? बेझिझक संपर्क करें: ईमेल (hello@puresecurity.com) या LINE (@PureSecurity)। हमारी API और एप्लिकेशन सुरक्षा समीक्षा सोर्स कोड विश्लेषण को मैन्युअल परीक्षण के साथ जोड़ती है, और हमारा पेनेट्रेशन टेस्टिंग नेटवर्क परिधि और विभाजन को सुरक्षित करता है।\n","date":"11 मार्च 2026","permalink":"https://puresecurity.com/hi/posts/api-penetration-testing-thailand/","section":"सुरक्षा विश्लेषण एवं तकनीकी सलाह","summary":"","title":"थाईलैंड में प्रभावी API पेनेट्रेशन टेस्टिंग"},{"content":"बढ़ती companies security leadership acquire करने के तरीके में structural gap है। Scale-up जिसमें 50 employees हों और serious enterprise pipeline हो, full-time CISO justify करने के लिए too small है, पर without one operate करने के लिए too exposed. Security purgatory में land होता है: over-stretched IT lead जो security hat पहनता है, enterprise prospect board या investor level पर questions पूछता है जिनके जवाब कोई नहीं दे सकता, और regulator जो programme के लिए accountable someone expect करता है।\nFractional CISO exactly वही gap close करने के लिए exist करता है।\nvCISO actually क्या करता है #Virtual CISO वह consultant नहीं है जो report write करके चला जाता है। Role leadership on retainer है: ऐसा named, accountable person जो security roadmap own करता है, board के सामने security represent करता है, और risk conversations carry करता है जो otherwise ऐसे किसी पर गिरती हैं जिसके पास authority या vocabulary नहीं होती।\nPractice में इसका मतलब है:\nBoard और committee reporting: technical risk को revenue, reputation और regulatory exposure की language में translate करना। Audit defence: regulators, external auditors और enterprise customers की security teams को controls walk-through कराना। Enterprise questionnaires: 200-question security reviews answer करना जो आपकी biggest deals gate करती हैं, credibly और fast। Budget और strategy: defensible security roadmap जो CFO scrutiny survive करे, क्योंकि वह बनाता है कोई जो ऐसा पहले defend कर चुका है। Incident governance: ऐसा decision-maker जो incidents run कर चुका है, ताकि first real crisis leadership के practice करने का first time न हो। इनमें से कोई भी week के 40 hours require नहीं करता। सब require करते हैं someone जो इन्हें real में, CISO level पर, more than once done कर चुका हो।\nScale-ups security leadership under-buy क्यों करते हैं #Smaller companies security को product की तरह buy करती हैं (EDR licence, scanner, firewall) और wonder करती हैं enterprise deals procurement में stall क्यों होते हैं। Reason यह है कि tools \u0026ldquo;क्या आपके पास controls हैं?\u0026rdquo; answer करते हैं पर \u0026ldquo;इन्हें own कौन करता है, governance कैसे होती है, और अपने board को prove कर सकते हो?\u0026rdquo; नहीं।\nEnterprise buyers और regulators really आपके tools audit नहीं करते। आपकी accountability structure audit करते हैं। vCISO वह structure supply करता है: named ownership, maintained risk register, governance cadence, और security narrative जो questioning के under together hold करती है।\nFull-time CISO भी यही provide करता है, पर ऐसी salary पर जो certain headcount past ही sense बनाती है, और hiring cycle जो six-twelve months ले सकता है, short runway पर 0 से 1 जाते समय जो आपके पास नहीं होता।\nEngineering के साथ alignment #Best security leadership engineering team से fight नहीं करती; align करती है। Hands-on vCISO developers से same language speak करता है, shipping velocity respect करता है, और policy PDF में रहने वाले controls से CI/CD pipeline में रहने वाले controls prefer करता है।\nGovernance-only advisor और hands-on CISO में distinction यही है: hands-on वाला platform team के साथ sit कर सकता है, actual architecture review कर सकता है, और regulatory requirement को pull request में turn कर सकता है। जब board report write करने वाला person वही हो जो threat model समझता है, strategy theoretical रहना बंद कर देती है।\nReal cost comparison #Fractional leadership evaluate करने का honest way दोनों options same page पर रखकर everything count करना है, सिर्फ salary नहीं।\nFull-time option. Region में genuine enterprise और regulatory experience वाला CISA commands total package well beyond base salary: annual compensation, bonus, benefits, typically equity component, क्योंकि serious candidates growth companies join expecting outcome share करना। Recruitment fees twenty-thirty percent first-year compensation add करो और hiring runway six-twelve months, full-time hire का first year commonly fractional alternative की recurring cost का several times होता है। फिर वह risk भी है जिसकी pricing hardest है: senior hire wrong fit turn out हुआ तो भी full severance cycle cost करता है।\nFractional option. Retainer covering defined number of days per month, no recruitment fee, no equity, notice period contract terms beyond नहीं। Board representation, audit defence और enterprise questionnaire coverage चाहने वाले scale-up के लिए यह typically full-time package के small fraction पर run करता है, delivering someone multiple companies पर job done वाला, आपकी company पर learning वाला नहीं।\nBreak-even. Fractional leadership pure economics पर win करती है जब तक demand genuinely continuous न हो जाए: sustained regulatory load, large engineering organisation needing daily partnership, या board permanent executive face चाहता हो। Most companies के लिए वह point well past stage arrive करता है जहां hiring currently affordable है, और good fractional arrangement transition gradual बनाता है: business grow होने पर days increase होते हैं, जब तक full-time sense बनाता है और vCISO recruit help और successor को handover करता है।\nEnterprise deal arithmetic. One more consideration whole comparison reframe करती है। Enterprise prospect security review stall हो जाए, deal procurement में sit करती है, sometimes annually worth entire security budget से ज्यादा। Review credibly within week answer करने वाला vCISO money cost नहीं करता; cases जहां matter करता है, retainer revenue unblocked के against rounding error है। Security leadership few functions में से एक है जहां spend directly deals won से tie हो सकता है risks avoided only से नहीं।\nConsidering fractional security leadership? सीधी समझ-जांच के लिए संपर्क करें: LINE (@PureSecurity) या email (hello@puresecurity.com). हमारी vCISO Advisory ex-CISO deliver करता है जो roadmap और board relationship own करता है। Fit right है या नहीं देखना हो तो Engineering \u0026amp; Scoping Session schedule करें और हम security leadership के आपके first 90 days map करेंगे।\n","date":"18 फ़रवरी 2026","permalink":"https://puresecurity.com/hi/posts/fractional-vciso-advisory-apac/","section":"सुरक्षा विश्लेषण एवं तकनीकी सलाह","summary":"","title":"APAC में स्केल-अप के लिए फ्रैक्शनल vCISO एडवाइजरी"},{"content":"क्रिप्टोग्राफी का एक असहज सच: केवल हैशिंग करना वास्तविक सुरक्षा के बराबर नहीं है। आप क्रेडिट कार्ड नंबर का SHA-256 हैश स्टोर कर सकते हैं, पूरी तरह से PCI DSS का अनुपालन कर सकते हैं, और फिर भी प्रभावी रूप से शून्य सुरक्षा पा सकते हैं, क्योंकि जिस मान को आपने हैश किया है उसमें ब्रूट फोर्स का विरोध करने के लिए पर्याप्त एन्ट्रॉपी नहीं है।\nइंजीनियरिंग टीमें अक्सर यह मान लेती हैं कि चूंकि हैश फ़ंक्शन एकतरफा (one-way) है, इसलिए डेटा सुरक्षित है। दोष गणितीय फ़ंक्शन में नहीं है; दोष इनपुट स्पेस के बहुत छोटे आकार में है।\nवास्तविक संख्याओं में एन्ट्रॉपी की समस्या #16-अंकीय कार्ड नंबर (PAN) यादृच्छिक नहीं होता:\nपहले 4 से 6 अंक जारीकर्ता पहचान संख्या (IIN / बैंक उपसर्ग) होते हैं, जो सार्वजनिक होते हैं। अंतिम अंक लुह्न एल्गोरिथ्म (Luhn Algorithm) द्वारा गणना किया गया चेकसम होता है। जब आप PCI DSS के अनुसार कार्ड को मास्क करते हैं (पहले 4-6 और अंतिम 4 अंक दिखाई देते हैं):\n4532 AAXX XXXX 1234 केवल 4 IIN अंकों के साथ, अज्ञात भाग केवल 8 अंक (100,000,000 संभावित मान) होता है। लुह्न चेकसम लागू करने के बाद, उनमें से केवल 10 में से 1 मान ही मान्य रहता है। वास्तविक खोज स्थान केवल 10 मिलियन (1 करोड़) मान है।\n10 मिलियन हैश का परीक्षण कितनी तेजी से हो सकता है? #SHA-256 अत्यधिक गति के लिए डिज़ाइन किया गया है:\nहार्डवेयर अनुमानित SHA-256 थ्रूपुट 1× RTX 4090 GPU ~8.5 बिलियन हैश / सेकंड 4× RTX 4090 क्लस्टर ~34 बिलियन हैश / सेकंड 8× RTX 4090 क्लस्टर ~68 बिलियन हैश / सेकंड एक सामान्य GPU पर 10 मिलियन संभावनाओं का परीक्षण करने में केवल एक सेकंड का एक हज़ारवां हिस्सा (0.001 सेकंड) लगता है।\nनिष्कर्ष स्पष्ट है: कम-एन्ट्रॉपी फ़ील्ड्स पर, SHA-2 सुरक्षित नहीं है, भले ही वह विनियामक रूप से अनुपालन योग्य हो।\n\u0026ldquo;Compliant\u0026rdquo; वास्तव में क्या अनुमति देता है #PCI DSS वास्तव में आपको PAN को SHA-256 से hash करने नहीं कहता। Requirement 3.5 कहती है कि आप PAN को strong cryptography से unreadable बनाएं, जो keyed hashes और encryption को स्पष्ट रूप से बताती है, और नोट करती है कि hashed and salted index स्वीकार्य है जहां salt गोपनीय हो और hash व्यावहारिक रूप से reversible न हो। समस्या यह है कि 10 मिलियन-मूल्य स्पेस का खाली, बिना salted SHA-256 व्यवहार में exhaustion द्वारा reversible है, इसलिए checklist tick पास होने पर भी यह requirement के इरादे को विफल करता है।\nMasking (पहले 4-6 और/या अंतिम 4 दिखाना) एक अलग नियंत्रण है: यह operator जो देखता है उसे सुरक्षा देता है, आप जो store करते हैं उसे नहीं। दोनों को आसानी से confuse किया जाता है, और यही confusion है जिससे masked-लेकिन-bare-hashed PAN production में पहुंच जाते हैं।\nइस प्रकार के डेटा को सही तरीके से कैसे सुरक्षित करें # डेटा को स्टोर ही न करें: टोकनाइजेशन (Tokenisation) और HSM का उपयोग करें। कुंजी-आधारित हैशिंग (HMAC with Pepper): डेटाबेस के बाहर संग्रहीत एक गुप्त कुंजी के साथ HMAC का उपयोग करें। मेमोरी-हार्ड फ़ंक्शंस का उपयोग करें: Argon2id या scrypt का उपयोग करें जिसमें प्रति-मान यादृच्छिक साल्ट (Salt) शामिल हो। हर जगह salts और peppers। प्रति-मान यादृच्छिक salt precomputed tables को असंभव बनाता है, और database के बाहर संग्रहीत गुप्त pepper offline cracking को आपके infrastructure तक सीमित कर देता है। flowchart TD A[PAN संग्रहीत करना है] --\u003e B{इंडेक्सिंग के लिए आवश्यक?} B -- नहीं --\u003e C[टोकनाइजेशन / HSM / वॉल्ट] B -- हाँ --\u003e D{गुप्त कुंजी उपलब्ध?} D -- हाँ --\u003e E[HMAC + Pepper] D -- नहीं --\u003e F[Argon2id / scrypt + Salt] style C stroke:#10B981,stroke-width:2px style E stroke:#10B981,stroke-width:2px style F stroke:#10B981,stroke-width:2px कार्ड से परे अन्य पहचानकर्ताओं पर भी लागू #यह राष्ट्रीय पहचान पत्र, फोन नंबर और जन्मतिथि जैसे सभी निश्चित-प्रारूप पहचानकर्ताओं पर समान रूप से लागू होता है।\nक्या आप अपनी संवेदनशील पहचानकर्ताओं की सुरक्षा को लेकर चिंतित हैं? तकनीकी समीक्षा के लिए संपर्क करें: ईमेल (hello@puresecurity.com) या LINE (@PureSecurity)। हमारी API और एप्लिकेशन सुरक्षा समीक्षा आपके क्रिप्टोग्राफ़िक कार्यान्वयन की जांच करती है।\n","date":"14 जनवरी 2026","permalink":"https://puresecurity.com/hi/posts/hashing-low-entropy-data-apac/","section":"सुरक्षा विश्लेषण एवं तकनीकी सलाह","summary":"","title":"APAC में कम एन्ट्रॉपी डेटा और क्रेडिट कार्ड का हैशिंग"},{"content":"","date":null,"permalink":"https://puresecurity.com/hi/tags/fintech--payments/","section":"Tags","summary":"","title":"Fintech \u0026 Payments"},{"content":"PCI DSS का सबसे common सवाल \u0026ldquo;कैसे comply करें?\u0026rdquo; नहीं है, बल्कि \u0026ldquo;हमें भी need है क्या?\u0026rdquo; है। Answer ज़्यादातर organisations के assumption से broader है, और wrong guess के consequences theoretical नहीं हैं: fines हैं, higher interchange fees हैं, और breach की situation में forensic costs और brand damage real money में measure होता है।\nShort answer #PCI Data Security Standard किसी भी entity पर apply होता है जो cardholder data store, process या transmit करती है, और उस entity पर भी जो उस data की security affect कर सकती है। यह deliberately wide है, और यह three groups sweep करता है जो routinely exempt assume कर लेती हैं।\n1. Card data store, process या transmit करने वाला anyone #यह obvious case है, पर यह card swipe करने वाले merchant से far more include करता है। इसमें आते हैं:\nCheckout form में card number लेने वाली e-commerce site. PAN \u0026ldquo;just for reconciliation\u0026rdquo; store कर लेने वाला ERP. Recorded line पर CRM में card numbers key करने वाला call centre. Payment gateway, PSP, acquirer और issuer जो इस data को daily touch करते हैं। Card data आपके systems पर land हो, even briefly, even memory में, तो आप scope में हैं। \u0026ldquo;Second के लिए hold करते हैं\u0026rdquo; exemption नहीं है; यह scope है।\n2. Third-party processor use करने पर भी #Single biggest misconception यह है: \u0026ldquo;हम Stripe / 2C2P / PayPal use करते हैं, इसलिए PCI DSS हमारी problem नहीं।\u0026rdquo; Third party आपका scope shrink करता है; eliminate नहीं करता।\nइसका usually मतलब (small organisation के लिए) यह है कि आप reduced validation form qualify करते हैं: full SAQ D के बजाय SAQ A या SAQ A-EP, क्योंकि card data आपके systems touch never करता। But obligations still: script integration correctly maintain करें, checkout page skimming free रखें, और third party को Requirement 12.8 के under manage करें। Validate still करते हैं; बस less validate करते हैं।\nTrap scope creep है। Bespoke field add कर दिया server-side capture, redirect own endpoint, silently SAQ A SAQ D move: dramatically larger obligation। Nobody tells happening।\n3. Banks और cardholder के upstream में बैठा हर कोई #Banks, acquirers, issuers और payment facilitators सिर्फ \u0026ldquo;in scope\u0026rdquo; होने तक सीमित नहीं हैं: यह ecosystem की सबसे heavily validated entities हैं। थाईलैंड में financial institutions PCI DSS के ऊपर Bank of Thailand के IT Risk और digital channel guidelines को भी answer करते हैं। Two regimes overlap करते हैं पर identical नहीं हैं, और BOT audit PCI DSS validation का substitute नहीं है।\nScope everything क्यों #PCI DSS की cost scope के साथ scale होती है। CDE (Cardholder Data Environment) के अंदर रहने वाला हर system, network और person full control set के subject है। इसलिए CDE को shrink करना आपका highest-leverage compliance activity है:\nCard data को tokenise करें ताकि PAN store करने के बजाय useless reference रहे। Payment systems को segmentation के पीछे isolate करें ताकि business का rest out of scope हो जाए। जो pieces touch नहीं करने हैं उन्हें validated service provider को deliberately outsource करें। Well-scoped environment six-month six-figure assessment को manageable, repeatable exercise में turn कर सकता है। Poorly scoped environment entire company audit करवाती है additional security benefit zero के साथ।\nflowchart TD A[Card data received] --\u003e B{Touch your systems?} B -- No --\u003e C[SAQ A / A-EP: reduced scope] B -- Yes --\u003e D[Full CDE: SAQ D / ROC] D --\u003e E{Tokenise and segment?} E -- Yes --\u003e F[Shrink CDE before audit] E -- No --\u003e G[Full assessment, every system] style F stroke:#10B981,stroke-width:2px style G stroke:#F43F5E,stroke-width:2px 4.0.1 game change #PCI DSS 4.0.1 ने वह formalise किया जो good engineering teams already doing थीं: compliance को annual event के बजाय continuous state treat करना, targeted risk analysis requirements, customised control approaches, और change के through security maintain करना। Message यह है कि point-in-time certificate enough no longer: standard controls expect करता है stay true assessments between।\nNot sure SAQ A, SAQ A-EP, full ROC? सीधी समझ-जांच के लिए संपर्क करें: LINE (@PureSecurity) या email (hello@puresecurity.com). कहां से शुरू करें #Audit commit करने से पहले PCI DSS Gap Assessment \u0026amp; Scope Reduction से begin करें: CDE shrink करें, segmentation test करें, और only then validate करें। Ready होने पर QSA-led audit आपको Bangkok में active assessor के साथ full ROC/AOC take कराता है।\n","date":"10 दिसंबर 2025","permalink":"https://puresecurity.com/hi/posts/pci-dss-compliance-thailand/","section":"सुरक्षा विश्लेषण एवं तकनीकी सलाह","summary":"","title":"थाईलैंड में PCI DSS 4.0.1 अनुपालन किसे चाहिए?"},{"content":"बीस साल पहले patching monthly chore था: spreadsheet, maintenance window, change advisory board, और prayer कि कुछ break न हो। Cadence work करती थी क्योंकि attackers defenders से roughly उतने ही slow थे। वह दुनिया gone है।\nआज vulnerability announce, weaponise, mass-exploit hours में हो सकती है। \u0026ldquo;Proof of concept\u0026rdquo; और \u0026ldquo;in the wild\u0026rdquo; के बीच window इतना collapse हो चुका है कि spreadsheet review करने वाला human already too late है। Vulnerability management process नहीं, pipeline बनना पड़ेगा।\nAI accelerant #दो trends AI को इस equation का dominant variable बना चुके हैं।\nपहला, AI-assisted defence: static analysers, fuzzers और code review tools अब flaws surface करने में human auditors से faster हैं। Good news है, और इसीलिए security teams findings में drown होती हैं।\nदूसरा, और more importantly, AI-assisted attacks. Researchers और attackers alike language models use करते हैं advisories triage करने के लिए, working exploits write करने के लिए, और known attack techniques mutate करके signatures bypass करने के लिए। Google के Project Zero ने और automated vulnerability discovery पर academic work ने दिखाया है कि once months की human effort अब dramatically compress हो सकती है।\nNet effect: discovery-to-exploitation gap हर month shrink होता है, और manual patch queue keep up no longer कर सकती। Speculation नहीं है: CISA Known Exploited Vulnerabilities catalog में visible है, listed flaws का typical time-to-exploit disclosure relative continuously shrinking है।\nCattle, pets नहीं #Phrase \u0026ldquo;cattle, not pets\u0026rdquo; early cloud era से आया: idea यह कि servers interchangeable, disposable resources हों hand-tuned machines names और personalities वाली नहीं। Patching पर perfectly applies होता है।\nServer pet हो तो gently patch करते हो: log in, fix apply, restart, hope. Cattle हो तो patch नहीं करते। Replace करते हो। New patched image CI/CD में bake करते हो, old instance destroy, new deploy. Patch build artifact है, production touch होने से पहले reviewed और tested।\nflowchart LR A[CVE published] --\u003e B[Automated triage] B --\u003e C{Build patched image} C --\u003e D[Test in pipeline] D --\u003e E[Deploy and rotate instances] E --\u003e F[Old image terminated] style C stroke:#0EA5E9,stroke-width:2px style F stroke:#10B981,stroke-width:2px Immutable infrastructure patching को risky manual operation से routine deployment convert कर देती है। Modern exploitation speed scale करने वाला यही model है, और इसे automated testing और deployment pipelines require करती है जो many teams अभी build नहीं कर पाई।\nVolume over prioritisation #40,000 findings return करने वाला scanner programme नहीं; noise है। Skill triage में है: findings में से कौन actually reachable, actually exploitable, actually critical path पर?\nCISA SSVC model right mindset capture करता है: prioritise by exploitation status, exposure, mission impact, CVSS score alone से नहीं। CVSS 9.8 internal-only non-routable service पर often less urgent CVSS 6.5 public endpoint पर known exploit wild में।\nLayers, क्योंकि individual layers WILL fail #Single control determined attacker survive नहीं करता। Defence depth हर layer के failure mode का acknowledgement:\nPatching attack surface reduce करता instant नहीं हो सकता। Network segmentation blast radius contains lagging patch के दौरान। Runtime detection catches slipped through patch cycle। Least privilege limits compromised asset reach। Backups tested recovery last line everything above fails। Goal हर exploit prevent करना नहीं है। Goal है कि हर individual failure survivable बने। Patch pipeline किसी week miss कर दे, तो segmentation और detection catch up करने का time buy करते हैं। Segmentation fail हो जाए, तो least privilege damage limit करता है। Layering ही वह तरीका है जिससे आप उस timeline से ahead रहते हैं जिसे आप fully control नहीं कर सकते।\nPatch queue pace struggle कर रहे हो? सीधी समझ-जांच के लिए संपर्क करें: LINE (@PureSecurity) या email (hello@puresecurity.com). यह कहां land होता है #हमारी Vulnerability Management service automated scanning और reporting side build करती है, जबकि Configuration \u0026amp; Architecture Assessment segmentation और identity boundaries test करता है जो patching gaps survivable बनाते हैं। Whole model चाहिए: pipeline, prioritisation, layers, तो Engineering \u0026amp; Scoping Session schedule करें।\n","date":"12 नवंबर 2025","permalink":"https://puresecurity.com/hi/posts/vulnerability-management-patching-apac/","section":"सुरक्षा विश्लेषण एवं तकनीकी सलाह","summary":"","title":"APAC में आधुनिक वल्नरेबिलिटी मैनेजमेंट और पैचिंग"},{"content":"","date":null,"permalink":"https://puresecurity.com/hi/tags/cost--strategy/","section":"Tags","summary":"","title":"Cost \u0026 Strategy"},{"content":"Enterprise security procurement में quiet irony है: organisation seven-figure licence pay करता है \u0026ldquo;unified platform\u0026rdquo; के लिए जो under the hood, bundle है open source projects का wrapped in dashboard और sales motion. Vendor ने detection engine invent नहीं किया: community ने किया। आप packaging के लिए pay कर रहे हो।\nयह software pay करने के against argument नहीं है। Argument knowing what you are buying के लिए है, और recognising के लिए कि small engineering team often more effective, more bespoke security stack build कर सकती है open source components से licence कर सकती है vendor से।\nUnique environment के लिए bespoke solutions #कोई दो environments alike नहीं, पर commercial tools average one के लिए built हैं। वे assume करते हैं network shape, data centre topology, logging model जो आपकी reality match नहीं कर सकता। Result tool है जो 80% environment fit करता है और awkwardly छोड़ देता other 20%, usually parts that matter, custom scripting anyway.\nOpen source relationship invert करता है। Stack compose करते हो architecture match करने को, reverse नहीं। Runtime security Falco से, network visibility Zeek से, host intrusion detection Wazuh से, container scanning Trivy से, vulnerability automation Nuclei से, static analysis Semgrep से। हर component एक चीज़ well करता है, और compose होते हैं।\nयह Unix philosophy applied to security है: small, sharp tools standard interfaces over communicate करते हुए, बजाय one monolith के जो everything own करता है।\nTools आपस बात करते हैं #Vendor suite centre of gravity बनना चाहती है। Everything feed करे उसे, use करे उसका agent, speak उसकी query language. वह silo ceiling बन जाता है: moment जब signal चाहिए जो वह natively produce नहीं करती, roadmap पर stuck हो।\nOpen source tools open formats और APIs around built हैं। Zeem JSON emit करता है। Falco stdout पर events emit करता है। Wazuh API via ingest करता है। Open interfaces over communicate करने के कारण same pipeline में route कर सकते हो, चाहे वह OpenSearch cluster हो, SIEM, plain log sink, और whole picture query करो one language से।\ngraph LR A[Falco: runtime] --\u003e E[OpenSearch / SIEM] B[Zeek: network] --\u003e E C[Wazuh: host] --\u003e E D[Nuclei: scanning] --\u003e E E --\u003e F[Detection and response playbooks] style E stroke:#0EA5E9,stroke-width:2px style F stroke:#10B981,stroke-width:2px Commercial suite composability give up करवाती है। Open source stack default बना देता है।\nPeople में invest करते हो, licences में नहीं #Licence recurring cost है जो moment you stop paying गायब, capability समेत। Open source stack recurring investment है आपके engineers में, जो tools के internals learn करते हैं वे operate करते हैं।\nLine item से ज्यादा matter करता है। Detection pipeline build करने वाला engineer समझता है alert क्यों fire हुई, false positive tune out कर सकता support ticket खोले बिना, और extend कर सकता है tool new threat आने पर। Organisation capability own करता है; rent नहीं करता।\nKey engineer move on करे, project उसके साथ die नहीं। Tooling version-controlled, documented, reproducible है, क्योंकि open source work by nature review exposed होती है। वही dynamic Eric S. Raymond described in The Cathedral and the Bazaar: many eyes on code bugs shallow बनाती हैं, knowledge transfer process का part बनाती हैं afterthought नहीं।\n\u0026ldquo;We already sell that\u0026rdquo; trap से बचें #Buy करने से पहले देखें already operate क्या करते हो। Surprising number organisations commercial SIEM licence करते हैं, commercial scanner, commercial EDR, फिर discover existing open source stack already produced same signal का 90% free में।\nPattern repeats: vendor sells \u0026ldquo;solution\u0026rdquo; orchestration layer over tools जो खुद run कर सकते हो, UI और support contract bolted on. Support contract genuine value रखती है people नहीं हों operate करने के लिए। But if people हैं, या build करना चाहते हो, open source path usually cheaper और effective।\nजब \u0026ldquo;buy\u0026rdquo; still right है #Blanket argument नहीं। Commercial tools win when:\nकोई tool operate करने को नहीं, और support product है। Vendor genuinely owns proprietary detection content replicate नहीं कर सकते। Vendor की regulatory attestation (सिर्फ use नहीं) required है। Point deliberate decision make करना है, eyes open about what is under the hood, default licence नहीं।\nWondering current tooling actually earning its licence? सीधी समझ-जांच के लिए संपर्क करें: LINE (@PureSecurity) या email (hello@puresecurity.com). Composition done for you चाहिए तो हमारा Configuration \u0026amp; Architecture Assessment reviews what you run और maps build-vs-buy path gaps के लिए, या bespoke stack design करने के लिए Engineering \u0026amp; Scoping Session schedule करें environment around।\n","date":"15 अक्टूबर 2025","permalink":"https://puresecurity.com/hi/posts/open-source-security-tools-thailand/","section":"सुरक्षा विश्लेषण एवं तकनीकी सलाह","summary":"","title":"थाईलैंड में ओपन सोर्स बनाम कमर्शियल सुरक्षा टूल्स"},{"content":"अधिकांश executives cybersecurity compliance को एक जरूरी tax की तरह experience करते हैं: हर साल एक बार assemble होने वाला binder, एक auditor जिससे survive करना होता है, और एक line item जो revenue generate करती कभी नहीं दिखती। यह framing उल्टी है, और इसकी कीमत audit fee से ज्यादा पड़ती है। ठीक से किया गया compliance security programme का सबसे मजबूत business case होता है, क्योंकि वह engineering effort को ऐसी चीज़ में बदल देता है जिसे buyers, partners और regulators वास्तव में verify कर सकते हैं।\nCompliance spend validate करता है, create नहीं #Security budgets finance के साथ चलता-फिरता argument हैं। \u0026ldquo;पिछले साल के spend से हमें क्या मिला?\u0026rdquo; fair question है, और \u0026ldquo;हमने threats block किए\u0026rdquo; वह answer है जो breach होते ही खराब लगने लगता है। Compliance frameworks आपको उस spend का external, independently verifiable yardstick देते हैं।\nजब आपका environment ISO/IEC 27001, NIST CSF या PCI DSS 4.0.1 से aligned है, तो आपका fund किया हर control एक ऐसी requirement से map होता है जिसे assessor test कर सकता है। इससे \u0026ldquo;हमें लगता है हम secure हैं\u0026rdquo; बदलकर \u0026ldquo;एक qualified third party ने attest किया है कि हम international bar meet करते हैं\u0026rdquo; हो जाता है। Board के लिए यह faith-based और evidence-based security investment का difference है।\nConverse भी matter करता है: framework के बिना spend उस vendor की ओर drift करता है जिसकी sales team सबसे जोरदार है। Compliance prioritisation force करता है। Vanity tool justify करना मुश्किल है जब आपका gap analysis कहे कि actual risk एक unpatched identity boundary है।\nTrust और assurance अब procurement criteria हैं #APAC के enterprise buyers अब sales deck में \u0026ldquo;हम security seriously लेते हैं\u0026rdquo; paragraph accept नहीं करते। वे security questionnaire भेजते हैं, फिर audit right, फिर penetration test. Regulated sectors में वे assessor भेजते हैं।\nउस conversation की currency compliance artefacts हैं:\nISO 27001 certificate questionnaire back-and-forth के weeks shortcut कर देता है। PCI DSS Report on Compliance (ROC) या AOC card data छूने वाले हर किसी के लिए mandatory hurdle है, और payment value chain में upstream भी requirement बनता जा रहा है। Bank of Thailand (BOT) IT Risk Guideline alignment financial institutions और उनके vendors को signal देता है कि आप local regulatory lens समझते हैं। इनमें से हर एक supplier होने की cost कम करता है। यह revenue impact है, सिर्फ risk reduction नहीं। Prospect जितनी जल्दी आपको clear कर पाता है, deal उतनी जल्दी close होती है, और आपकी engineering team product ship करने के बजाय questionnaires के जवाब देने में उतनी कम खिंचती है।\nCompliance बड़े sectors और बड़े customers के doors खोलता है #Compliance का सबसे under-discussed फायदा access है। Government tenders, financial services, healthcare और थाईलैंड व पूरे APAC की large enterprise procurement routinely international standard को bid करने की precondition बना देती हैं, nice-to-have नहीं।\nजो growing software company ISO 27001 land कर लेती है, वह अचानक उन contracts के लिए qualify करने लगती है जिनसे वह पहले filter out हो जाती थी। PCI DSS 4.0.1 maintain करने वाली fintech ऐसे acquirers और PSP partners onboard कर सकती है जो वरना relationship decline कर देते। NIST CSF से align हुई regional firm US-headquartered parent company को credibly जवाब दे सकती है जो बार-बार पूछती है \u0026ldquo;आप किस framework पर operate करते हो?\u0026rdquo;\nCompliance असर में market-access key है। हर framework customers की एक नई class unlock करता है जो certificate को पहली meeting से पहले minimum bar मानती है।\nResilient, secure services ही असली product हैं #यहां वह part है जो \u0026ldquo;compliance paperwork है\u0026rdquo; narrative में खो जाता है: ज़्यादातर framework controls बस अच्छी engineering है, लिखी हुई।\nAccess control और least privilege lateral movement कम करते हैं। Change management और patching known exploits की window सिकोड़ते हैं। Logging और monitoring blind outages को diagnosable incidents में बदलते हैं। Backup और recovery testing outage और business-ending event का difference है। IBM की Cost of a Data Breach research consistently पाती है कि lower breach cost का strongest predictor mature incident response और tested control environment है: exactly वे चीज़ें जो एक framework आपसे maintain करवाता है। Verizon DBIR attacker की side से वही point बनाता है: ज़्यादातर incidents known, patchable weaknesses exploit करते हैं, जिन्हें compliance-driven patch programme पहले ही address कर चुका होता।\nदूसरे शब्दों में, compliance है संगठन का resilience को institutionalise करने का तरीका। यह एक talented engineer जो एक server harden करता है, और उस संगठन का difference है जो हर server harden करता है, default रूप से, launch पर और हमेशा।\nBoard के लिए इसे frame करें #अगर budget defend करने वाले आप हैं, तो compliance को cost of doing business pitch करना बंद करें। इसे ऐसे pitch करें:\nAssurance: independently attested controls जो enterprise deals faster close कराते हैं। Access: regulated और enterprise procurement की qualification जिसमें आप वरना enter नहीं कर सकते। Evidence: security spend का measurable return, vague promise नहीं। Resilience: institutionalised engineering discipline जो staff turnover survive करती है। ऐसा business case जो CFO read कर सके और CISO के पीछे खड़ा हो सके।\nISO 27001, NIST CSF या Bank of Thailand guidelines के बारे में quick सवाल है? सीधी समझ-जांच के लिए संपर्क करें: LINE (@PureSecurity) या email (hello@puresecurity.com). कहां से शुरू करें #ज़्यादातर organisations को ocean boil करने की जरूरत नहीं। Gap assessment से शुरू करें उस एक framework के against जिसके बारे में आपका सबसे बड़ा customer actually पूछता है, real exposure वाले gaps close करें, और certificate को engineering के पीछे follow करने दें, उल्टा नहीं।\nअगर आप इसे अपने specific roadmap पर map करवाना चाहें, तो Engineering \u0026amp; Scoping Session schedule करें और हम framework को concrete engineering tasks की list में translate करेंगे।\n","date":"17 सितंबर 2025","permalink":"https://puresecurity.com/hi/posts/roi-cybersecurity-compliance-apac/","section":"सुरक्षा विश्लेषण एवं तकनीकी सलाह","summary":"","title":"APAC में साइबरसिक्योरिटी अनुपालन का व्यावसायिक ROI"},{"content":"दक्षिण पूर्व एशिया (ASEAN) में विस्तार करने वाली फिनटेक कंपनियों को विभिन्न विनियामकों का सामना करना पड़ता है, जिनमें से प्रत्येक की अपनी प्राथमिकताएं, समयसीमा और परिभाषाएं हैं। सिंगापुर के मौद्रिक प्राधिकरण (MAS) के अनुकूल बनाया गया सुरक्षा ढांचा फिलीपींस के सेंट्रल बैंक (BSP) के निरीक्षण में कमियां छोड़ सकता है। इसी तरह बैंक नेगारा मलेशिया (BNM) के लिए तैयार किए गए नियंत्रण बैंक ऑफ थाईलैंड (BOT) के परीक्षकों को संतुष्ट करने में असमर्थ हो सकते हैं।\nयह कोई काल्पनिक समस्या नहीं है। हमने संगठनों को ऑडिट के बीच में यह महसूस करते देखा है कि उनकी लॉग रिटेंशन अवधि एक नियामक को संतुष्ट करती है लेकिन दूसरे को नहीं। यह मान लेना कि \u0026ldquo;एशियाई नियम\u0026rdquo; एक जैसे हैं, एक बेहद महंगी भूल साबित हो सकती है।\nवे एक जैसे बिल्कुल नहीं हैं।\nचार मुख्य नियामकों की तुलना # बैंक ऑफ थाईलैंड (BOT) मौद्रिक प्राधिकरण सिंगापुर (MAS) बैंक नेगारा मलेशिया (BNM) बांग्को सेंट्रल एनजी पिलिपिनास (BSP) प्राथमिक निर्देश IT Risk Guidelines / Digital Channel Security Technology Risk Management Guidelines Risk Management in Technology (RMiT) IT Risk Management Framework दायरा बैंक, PSPs, ई-मनी जारीकर्ता, फिनटेक बैंक, बीमाकर्ता, पूंजी बाजार संस्थान, भुगतान सेवाएं लाइसेंस प्राप्त बैंक, इस्लामिक बैंक, ई-मनी जारीकर्ता बैंक, गैर-बैंकिंग वित्तीय संस्थान, ई-मनी, VASPs लॉग संरक्षण (Log Retention) न्यूनतम 1 वर्ष (90 दिन सक्रिय/हॉट स्टोरेज) लेनदेन रिकॉर्ड के लिए 5 वर्ष; जोखिम मूल्यांकन के अनुसार सिस्टम लॉग न्यूनतम 1 वर्ष, ऑडिट ट्रेल के लिए 7 वर्ष अनुशंसित सभी सुरक्षा-संबंधित लॉग्स के लिए न्यूनतम 3 वर्ष उल्लंघन की सूचना (Breach Notification) BOT को 24 घंटे के भीतर; प्रभावित व्यक्तियों को PDPA के तहत 72 घंटे में गंभीर घटनाओं के लिए 1 घंटे के भीतर; रूट-कॉज रिपोर्ट 14 दिनों में BNM को ईमेल द्वारा 1 घंटे के भीतर; औपचारिक लिखित रिपोर्ट 7 दिनों में BSP को 2 घंटे के भीतर; विस्तृत तकनीकी रिपोर्ट 14 दिनों में पेनेट्रेशन टेस्टिंग वार्षिक, या महत्वपूर्ण सिस्टम परिवर्तनों के बाद वार्षिक; TRM दिशानिर्देशों द्वारा परिभाषित दायरा वार्षिक; इंटरनेट और महत्वपूर्ण आंतरिक सिस्टम दोनों शामिल वार्षिक; महत्वपूर्ण सिस्टम परिवर्तनों के बाद अतिरिक्त परीक्षण जहां नियम टकराते हैं #लॉग संरक्षण: तीन साल का जाल #सबसे आम सीमा पार विनियामक आश्चर्य लॉग रिटेंशन है। जो संगठन BOT की एक साल की आवश्यकता को पूरा करने के लिए लॉगिंग अवसंरचना बनाता है, वह BSP की तीन साल की अनिवार्य सुरक्षा लॉग आवश्यकता में विफल हो जाएगा। 3 साल के सक्रिय सर्च करने योग्य लॉग्स को स्टोर करने की लागत और आर्किटेक्चर 1 साल के बैकअप से काफी अलग है।\nव्यावहारिक सलाह: अपनी लॉगिंग पाइपलाइन को उन सभी क्षेत्रों में सबसे लंबी आवश्यक संरक्षण अवधि के लिए डिज़ाइन करें जहां आप काम करते हैं।\nडेटा संरक्षण अधिकारी (DPO) आवश्यकताएं #मलेशिया का PDPA कानून स्पष्ट रूप से अनिवार्य करता है कि DPO एक मलेशियाई नागरिक या स्थायी निवासी होना चाहिए (धारा 12, पर्सनल डेटा प्रोटेक्शन एक्ट 2010)। थाईलैंड के PDPA में यह राष्ट्रीयता खंड नहीं है, लेकिन व्यवहार में BOT परीक्षाएं थाई भाषा में आयोजित की जाती हैं और स्थानीय नियामक विशेषज्ञता की मांग करती हैं।\nसिंगापुर अपने MAS TRM Guidelines में सिद्धांत-आधारित दृष्टिकोण अपनाता है, जो बोर्ड-स्तरीय जवाबदेही तय करता है लेकिन DPO की योग्यताओं को निर्धारित नहीं करता।\nBSP Circular 1105 CISO या समकक्ष मांगता है पर राष्ट्रीयता निर्दिष्ट नहीं करता।\nक्षेत्रीय संगठनों के लिए इसका मतलब:\nसिंगापुर स्थित group DPO मलेशियाई आवश्यकताएं पूरी नहीं कर सकता Thai national DPO में MAS reporting हेतु आवश्यक English proficiency की कमी हो सकती है Philippines delegated local authority वाले regional appointee स्वीकार कर सकता है व्यावहारिक सलाह: regional compliance team बनाने से पहले DPO आवश्यकताओं का map बनाएं। कई मामलों में, regional head को report करने वाले local representatives नियुक्त करना central oversight और local regulatory expectations दोनों को पूरा करता है।\nउल्लंघन सूचना: समयसीमा की संवेदनशीलता #सूचना विंडो 1 घंटे (गंभीर घटनाओं के लिए MAS) से लेकर 72 घंटे (थाई PDPA प्रभावित व्यक्तियों के लिए) तक है। यदि कोई घटना गैर-कार्य घंटों के दौरान होती है, तो BOT की 24 घंटे की विंडो के अनुसार तैयार की गई प्रक्रिया MAS की 1 घंटे की समयसीमा को चूक जाएगी।\nपरिदृश्य BOT (थाईलैंड) MAS (सिंगापुर) BNM (मलेशिया) BSP (फिलीपींस) पृथक टेस्ट सर्वर पर रैनसमवेयर भौतिक प्रभाव होने पर रिपोर्ट योग्य बिना आइसोलेशन देखे 1 घंटे में रिपोर्ट योग्य 1 घंटे में रिपोर्ट योग्य 2 घंटे में रिपोर्ट योग्य गलत कॉन्फ़िगरेशन से ग्राहक डेटा लीक हाँ + PDPA व्यक्तिगत सूचना हाँ + PDPA व्यक्तिगत सूचना हाँ + PDPA व्यक्तिगत सूचना हाँ + NPC व्यक्तिगत सूचना तृतीय-पक्ष विक्रेता डेटा ब्रीच BOT को सूचित करना आपका दायित्व MAS को सूचित करना आपका दायित्व BNM को सूचित करना आपका दायित्व BSP को सूचित करना आपका दायित्व जहां सामंजस्य संभव है #अंतर के बावजूद, सभी चार नियामक निम्नलिखित की अपेक्षा करते हैं:\nप्रौद्योगिकी जोखिम के लिए बोर्ड-स्तरीय जवाबदेही महत्वपूर्ण प्रणालियों का नियमित पेनेट्रेशन टेस्टिंग गंभीरता के आधार पर परिभाषित SLAs के साथ कमजोरी प्रबंधन (Vulnerability Management) न्यूनतम विशेषाधिकार (Least Privilege) और भूमिकाओं का पृथक्करण परीक्षण किए गए इंसिडेंट रिस्पांस प्लान तृतीय-पक्ष विक्रेता जोखिम प्रबंधन मुख्य स्रोत दस्तावेज़ # Bank of Thailand IT Risk Guidelines BOT Notification on Digital Channel Security Services MAS Technology Risk Management Guidelines MAS Notice on Cyber Hygiene MAS Notice 826: Prevention of Money Laundering and Countering the Financing of Terrorism BNM Risk Management in Technology (RMiT) BSP Memorandum M-2020-022: Information Technology Risk Management Framework BSP Circular 1105: Enhanced Corporate Governance Guidelines Thailand Personal Data Protection Act (PDPA) Singapore Personal Data Protection Act Malaysia Personal Data Protection Act Philippines Data Privacy Act प्रवर्तन का अंतर #नियामकीय अपेक्षाएं एक बात हैं; प्रवर्तन की तीव्रता दूसरी। इस अंतर को समझना compliance निवेश को प्राथमिकता देने में मदद करता है।\nMAS क्षेत्र का सबसे तकनीकी रूप से परिष्कृत नियामक माना जाता है। इसकी जांच केवल नीति के अस्तित्व नहीं, बल्कि कार्यान्वयन की गहराई की जांच करती है। MAS ने technology risk विफलताओं के लिए जुर्माने और व्यापार प्रतिबंधों सहित सार्वजनिक प्रवर्तन कार्रवाइयां की हैं, जिनमें 2023 में OCBC पर S$3.8 मिलियन का जुर्माना अपर्याप्त anti-money laundering नियंत्रणों के लिए शामिल है।\nBOT ने digital banking दिशानिर्देश जारी होने के बाद से प्रवर्तन काफी बढ़ाया है। जांच में अब केवल दस्तावेज़ समीक्षा नहीं, बल्कि तकनीकी परीक्षण भी शामिल है। हालांकि, यह नियामक MAS की तुलना में अधिक कार्यान्वयन मार्गदर्शन देता है, जिससे व्याख्या की अस्पष्टता कम होती है।\nBNM RMiT framework के निर्धारक अधिनियमों द्वारा समर्थित मजबूत प्रवर्तन बनाए रखता है। यह निर्धारक स्वभाव कम व्याख्या की मांग करता है, लेकिन वैकल्पिक दृष्टिकोणों को लागू करने की लचीलापन भी कम देता है।\nBSP अपनी पर्यवेक्षण क्षमता को सक्रिय रूप से मजबूत कर रहा है। हाल की पहलें बताती हैं कि प्रवर्तन तीव्रता MAS स्तर की ओर बढ़ेगी, जिससे वर्तमान compliance कमियां भविष्य की जांच खोज बन जाएंगी।\nव्यावहारिक सिफारिशें # कठोरतम नियम के लिए डिज़ाइन करें: फिलीपींस में काम करते हैं तो 3 साल का लॉग रिटेंशन रखें। कंट्रोल-टू-रेग्युलेशन मैपिंग बनाएं: एक स्पष्ट मैट्रिक्स रखें जो दर्शाए कि कौन सा तकनीकी नियंत्रण किस विनियामक नियम को पूरा करता है। पारस्परिकता न मानें: MAS ऑडिट पास करने से BOT ऑडिट में छूट नहीं मिलती। स्थानीयकृत इंसिडेंट प्लेबुक्स बनाएं: देश-विशिष्ट रिपोर्टिंग टेम्पलेट्स और संपर्क सूचियां पहले से तैयार रखें। नए नियामकों से जल्दी जुड़ें। नए बाजार में प्रवेश करते समय deployment के बाद नहीं, पहले local regulator से संवाद शुरू करें। जल्दी जुड़ाव उन अपेक्षाओं को सामने लाता है जो प्रकाशित दिशानिर्देश पूरी तरह capture नहीं करते। क्या आप कई आसियान देशों में परिचालन कर रहे हैं? विनियामक मैपिंग के लिए हमसे संपर्क करें: ईमेल (hello@puresecurity.com) या LINE (@PureSecurity)। हमारी विनियामक अनुपालन (Regulatory Compliance) सेवा आपके तकनीकी नियंत्रणों को BOT, MAS, BNM और BSP की आवश्यकताओं के साथ मैप करती है।\n","date":"14 मई 2025","permalink":"https://puresecurity.com/hi/posts/asean-cyber-regulations-comparison/","section":"सुरक्षा विश्लेषण एवं तकनीकी सलाह","summary":"","title":"आसियान साइबर विनियमों की तुलना: BOT बनाम MAS बनाम BNM बनाम BSP"},{"content":"","date":null,"permalink":"https://puresecurity.com/hi/tags/cloud-security/","section":"Tags","summary":"","title":"Cloud Security"},{"content":"क्लाउड गति को पुरस्कृत करता है। एक इंजीनियरिंग टीम एक ही दोपहर में पूरा प्रोडक्शन वातावरण तैयार कर सकती है: कंप्यूट, स्टोरेज, डेटाबेस, लोड बैलेंसर: सभी CLI या टेराफॉर्म फ़ाइल से। लेकिन वही गति गलतियों पर भी लागू होती है। एक स्टोरेज बकेट जिसे डेमो के लिए सार्वजनिक किया गया और वापस निजी नहीं किया गया; एक सुरक्षा समूह जिसे समयसीमा से पहले कनेक्टिविटी ठीक करने के लिए 0.0.0.0/0 पर खोला गया; कोड रिपॉजिटरी में गलती से डाला गया एडमिन क्रेडेंशियल। इनमें से प्रत्येक में कुछ सेकंड लगते हैं, और प्रत्येक पूरे व्यवसाय को उजागर कर सकता है।\nयह क्लाउड सुरक्षा की मूल विषमता है: ऑन-प्रिमाइसेस में, एक गलती आमतौर पर एक निजी नेटवर्क के अंदर एक सर्वर को प्रभावित करती है। क्लाउड में, एक एकल सेटिंग अक्सर डिफ़ॉल्ट रूप से विश्व स्तर पर सुलभ हो जाती है। हमलावर अब सिस्टम में सेंध नहीं लगाते, वे बस उन दरवाजों से लॉग इन करते हैं जो अनजाने में खुले रह गए थे।\nक्लाउड घटनाओं में गलत कॉन्फ़िगरेशन क्यों हावी है #सार्वजनिक डेटा उल्लंघनों के विश्लेषण से एक स्पष्ट पैटर्न सामने आता है। अधिकांश क्लाउड डेटा लीक जटिल जीरो-डे हमलों के कारण नहीं होते, बल्कि ज्ञात और प्रलेखित सेटिंग्स के असुरक्षित रह जाने के कारण होते हैं:\nसार्वजनिक रूप से खुला ऑब्जेक्ट स्टोरेज (S3 Buckets): बैकअप या ग्राहक रिकॉर्ड वाले बकेट जो एक साधारण फ्लैग के कारण पूरे इंटरनेट के लिए खुले हैं। अत्यधिक अनुमेय IAM नीतियां: Resource: \u0026quot;*\u0026quot; पर Action: \u0026quot;*\u0026quot; जैसी नीतियां जिन्हें सुविधा के लिए दिया गया और बाद में कभी सीमित नहीं किया गया। असुरक्षित प्रबंधन कंसोल: बिना आईपी प्रतिबंध और बिना अनिवार्य मल्टी-फैक्टर ऑथेंटिकेशन (MFA) के एडमिन खाते। अनएन्क्रिप्टेड डेटा स्टोर: स्नैपशॉट और वॉल्यूम जो संसाधन पहचानकर्ता प्राप्त करने वाले किसी भी व्यक्ति द्वारा पढ़े जा सकते हैं। कोड में क्रेडेंशियल्स: सार्वजनिक रिपॉजिटरी में कमिट की गई API कुंजियाँ। आप उसे ठीक नहीं कर सकते जिसे आप देख नहीं सकते #पहला महत्वपूर्ण कदम यह स्वीकार करना है कि क्लाउड की सतह वास्तव में कितनी बड़ी है। एक मध्यम आकार का संगठन आमतौर पर विभिन्न टीमों द्वारा बनाए गए दर्जनों खातों और क्षेत्रों में हजारों क्लाउड संसाधनों का संचालन करता है।\nनिरंतर निगरानी (Continuous Monitoring) इसका समाधान है: कॉन्फ़िगरेशन स्थिति को उसी तरह ट्रैक करें जैसे आप एप्लिकेशन की उपलब्धता को ट्रैक करते हैं।\ngraph LR A[क्लाउड APIs\nकॉन्फ़िगरेशन स्थिति] --\u003e B[निरंतर मूल्यांकन] C[IaC रिपॉजिटरी\nTerraform आदि] --\u003e B D[पहचान और\nएक्सेस लॉग] --\u003e B B --\u003e E{गंभीरता छंटनी} E --\u003e|क्रिटिकल जोखिम| F[तत्काल समाधान:\nस्वचालित] E --\u003e|विचलन और शोर| G[बेसलाइन ट्यूनिंग,\nनियोजित सुधार] style B stroke:#0EA5E9,stroke-width:2px style F stroke:#EF4444,stroke-width:2px style G stroke:#10B981,stroke-width:2px CSPM उपकरण और प्रभावी उपयोग #क्लाउड सिक्योरिटी पोस्चर मैनेजमेंट (CSPM) टूल्स CIS बेंचमार्क के विरुद्ध आपके लाइव वातावरण की निरंतर तुलना करते हैं।\nअलर्ट की अधिकता से बचने के 3 नियम:\nइंटरनेट-फेसिंग जोखिम को पहले ठीक करें: सार्वजनिक स्टोरेज और खुले मैनेजमेंट पोर्ट्स सर्वोच्च प्राथमिकता हैं। समस्या को स्रोत (IaC Code) में ठीक करें: कंसोल में मैन्युअल बदलाव करने से समस्या केवल अस्थायी रूप से हल होती है; टेराफॉर्म कोड को सुधारें। सख्त फिल्टरिंग और दस्तावेजीकरण: अप्रासंगिक चेतावनियों को स्पष्ट औचित्य के साथ हटाएं ताकि टीम केवल वास्तविक जोखिमों पर ध्यान दे सके। सर्वश्रेष्ठ नियंत्रण: प्रशिक्षित इंजीनियर #ऊपर की हर तकनीकी परत अंततः इस बात पर निर्भर करती है कि लोग समझते हैं कि कोई सेटिंग क्यों मायने रखती है। जो इंजीनियर समझता है कि ऑब्जेक्ट-स्टोरेज ACL नेटवर्क रूटिंग से स्वतंत्र होती हैं, वह किसी बकेट को त्वरित डेमो के लिए विश्व-पठनीय बनाने से पहले रुककर सोचेगा। जिसे यह कभी समझाया नहीं गया, वह बिना सोचे क्लिक कर देगा।\nवास्तविक इंजीनियरिंग संस्कृति में फिट होने वाले व्यावहारिक कदम:\nसुरक्षित रास्ता को आसान रास्ता बनाएं। Golden Terraform मॉड्यूल, पूर्व-अनुमोदित आर्किटेक्चर पैटर्न, और डिफ़ॉल्ट रूप से एन्क्रिप्शन व लॉगिंग सक्षम आंतरिक मॉड्यूल, किसी भी policy दस्तावेज़ से बेहतर हैं। छोटे, हाथ-on सत्र चलाएं। अपने ही वातावरण में, अपने ही CSPM निष्कर्षों की साझा समीक्षा करने के 90 मिनट, generic स्लाइड्स के एक दिन से अधिक सिखाते हैं। Near-miss के लिए blameless post-mortem। attacker से पहले सहकर्मी द्वारा पकड़ा गया खुला बकेट एक मुफ़्त सबक है। इसे लिखें, व्यापक रूप से साझा करें, और उस module को बदलें जिसने इसे संभव बनाया। इंजीनियरों को scoping चर्चाओं में जल्दी शामिल करें। security review डिज़ाइन समय पर हो तो वह घंटों का काम है; launch के बाद हो तो rework। Admin शिक्षा tooling का कोमल विकल्प नहीं है: यह आपके द्वारा खरीदे गए हर अन्य नियंत्रण का गुणक है।\nइस तिमाही के लिए कार्ययोजना # सप्ताह 1 से 2: सभी क्लाउड खातों और संसाधनों की पूर्ण इन्वेंट्री। सप्ताह 3 से 6: इंटरनेट-फेसिंग सभी सार्वजनिक जोखिमों का तत्काल समाधान। सप्ताह 7 से 12: इन्फ्रास्ट्रक्चर-ऐज़-कोड (IaC) टेम्प्लेट्स में गार्डरेल्स लागू करना और इंजीनियरिंग टीम का व्यावहारिक प्रशिक्षण। क्या आप जानना चाहते हैं कि आपका क्लाउड वातावरण वर्तमान में क्या उजागर कर रहा है? तकनीकी समीक्षा के लिए संपर्क करें: ईमेल (hello@puresecurity.com) या LINE (@PureSecurity)। हमारा कॉन्फ़िगरेशन और आर्किटेक्चर मूल्यांकन आपके क्लाउड का CIS मानकों के अनुसार विश्लेषण करता है, और हमारा कमजोरी प्रबंधन निरंतर सुरक्षा सुनिश्चित करता है।\n","date":"16 अप्रैल 2025","permalink":"https://puresecurity.com/hi/posts/cloud-misconfiguration-security-apac/","section":"सुरक्षा विश्लेषण एवं तकनीकी सलाह","summary":"","title":"क्लाउड गलत कॉन्फ़िगरेशन: APAC में सामने छिपा सुरक्षा जोखिम"},{"content":"हर security budget eventually finance से same question meet करता है: जब कुछ हुआ ही नहीं तो prevention पर इतना spend क्यों? Fair question है, और numerical answer deserve करता है। Honest answer यह है कि alternative की price निकालो, क्योंकि Southeast Asia में data breach की cost अब abstract नहीं है। वह statutes में, regulator penalty schedules में और card brand rules में written है जो Bangkok, Singapore, Kuala Lumpur और beyond के businesses पर directly apply होते हैं।\nजब आप दोनों columns side by side रखते हैं तो conclusion consistent होता है: protections incident की cost का fraction cost करती हैं, even before you count वह damage जो invoice पर कभी appear नहीं होता।\nRegulators floor set करते हैं, ceiling नहीं #Region के data protection regimes quickly mature हुए हैं और अब financial teeth carry करते हैं:\nJurisdiction Regime Maximum exposure Thailand PDPA THB 5 million administrative fines plus sensitive-data offences पर criminal liability Singapore PDPA Annual local turnover का 10% तक जब turnover SGD 10 million से above हो Malaysia PDPA Amendment Act 2024 Breach notification failures पर higher fines और imprisonment; processors पर direct obligations Indonesia PDP Law 27/2022 Annual revenue का 2% तक fines illegally processed data destruction समेत Australia Privacy Act amendments AUD 50 million, benefit gained तीन गुना, या adjusted turnover का 30% Philippines Data Privacy Act 2012 PHP 5 million per offence responsible officers imprisonment समेत इस table के three points numbers themselves से ज़्यादा matter करते हैं।\nपहला: ये figures maximum हैं और regulators ने use करते दिखाया है। Singapore PDPC हर enforcement decision publish करता है, six-figure penalties समेत admin accounts पर two-factor authentication जैसी basic safeguards fail करने वालों के against। Thailand PDPC corrective orders issue करना begin कर चुका है। Region का pattern one direction only में है: upward.\nदूसरा: Malaysian amendment structural shift है, number change सिर्फ नहीं। Mandatory breach notification, processors पर direct statutory duties और mandatory DPO appointments का मतलब है vendors और service providers अब अपनी liability carry करते हैं। आप Malaysia services sell करते हो या ऐसे providers buy करते हो, यह change आपके contracts touch करती है।\nतीसरा: Indonesia revenue-percentage model fine आपकी success के साथ scale करती है। Growing Indonesian business के लिए five years बाद वाली breach same breach today से far more cost कर सकती है।\nFine rarely largest line item होती #Executives regulatory penalty anchor करते हैं क्योंकि public quotable है। Practice में organisations report करते हैं fine के around everything ज़्यादा cost करता है:\nInvestigation response. Forensic investigators, emergency legal counsel और external incident response cheap come नहीं करते। ये crisis rates पर time pressure under bill करते हैं। DFIR retainer exactly उसी spend को panic pricing से planned relationship convert कर देता है।\nNotification scale पर. Breach notification laws affected individuals को fixed deadlines के अंदर contact require करते हैं। Hundreds thousands के customer base पर इसका मतलब है call centres, mail-outs और credit monitoring offers, all delivered while आपकी team service restore कर रही है।\nBusiness interruption. Containment के लिए offline systems revenue produce नहीं करते। Ransomware incidents routinely operations days या weeks shutdown रखते हैं, recovery costs, rebuilt infrastructure, overtime और emergency hardware regulator decision आने से long before land करते हैं।\nCustomer partner churn. IBM Cost Data Breach Report years tracking करती है: breach costs large share incident after one-two years emerge करती है, driven largely customers competitors move जाने से। Global averages USD 5 million near हैं, regional studies consistently find emerging-market organisations breaches identify contain longer take drives costs up।\nContractual consequences. Enterprise customers increasingly security clauses embed audit rights termination triggers संग। Brech उन customers decision hands देती है rather they never had make।\nPCI DSS real penalties private regulator #Organisation जो cardholder data handle करती है, privacy regulators के ऊपर enforcement की second layer face करती है। Card brands merchants directly fine नहीं करते: acquiring banks penalties assess merchant agreement pass through। Commonly reported figures run thousands hundreds thousands month compliance non-continued escalating acceptance loss breaches suffering compliant non organisations लिए।\nCards acceptance losing fine नहीं है। Retail hospitality businesses region में existential event है। Business case behind properly PCI DSS scope reduction gap assessment paperwork treating assessment fee exposure closes rounding error against।\nNumbers next putting each other #Consider करें एक Thai fintech: staff 200, payments process, customer KYC records hold:\nPrevention annualised: part-time security engineer time, DFIR retainer, vulnerability scanning patching discipline, year once tabletop exercise, periodic assessments PDPA PCI DSS requirements against। Size organisations total lands somewhere low hundred thousands baht।\nSingle breach: THB million maximum administrative penalty, weeks forensics fees, base customer across notification, termination clauses invoking enterprise customers, months rebuilding trust commercial returns never fully।\nPrecision comparison shape see need नहीं। Prevention subscription; lawsuit breach interest with। Probability incident given asymmetry columns expected-value argument straightforward makes even year low।\nCost down moves actually what #Spending equally breach cost reduce नहीं करता। Research industry controls short list measurable identifying keeps impact:\nContainment detection fast। Compromise containment between day every adds cost। Monitoring tested escalation paths investment highest-leverage single है। Plans response tested। Organisations first 48 hours rehearse better decisions make real deciding time ones than। Exercise tabletop crisis cyber gaps finds still free fix expensive later would be। Footprint data reduced। Hold leak cannot what do not। Retention limits encryption likelihood radius blast shrink both breach। Segmentation privilege least। Incidents contained sprawling cheaper returning keep segmentation network control risk remediation cost both lowering। Technology exotic require none these। Engineering attention applied consistently require starting before incident after rather than।\nExposure breach organisation realistic view closing versus cost want? सीधी समझ-जांच के लिए संपर्क करें: LINE (@PureSecurity) या email (hello@puresecurity.com). Practice Compliance Regulatory हमारी obligations maps frameworks regional DSS PCI PDPA advisory vCISO build helps business case spending where measurably reduces focus incident cost करने। Or Session Scoping Engineering schedule numbers through work team your will we।\n","date":"19 मार्च 2025","permalink":"https://puresecurity.com/hi/posts/data-breach-cost-southeast-asia/","section":"सुरक्षा विश्लेषण एवं तकनीकी सलाह","summary":"","title":"दक्षिण पूर्व एशिया में डेटा ब्रीच की असली कीमत"},{"content":"Southeast Asia में payments handle करने वाला हर organisation eventually दोनों frameworks meet करता है, often same quarter में। Vendor onboarding पर bank आपकी ISO 27001 certificate मांगता है। Acquiring bank same time पर PCI DSS compliance evidence मांगती है। दोनों conversations similar sound करती हैं, दोनों में auditors, controls और annual cycles होते हैं, और conclude करना tempting है कि interchangeable हैं।\nनहीं हैं। Difference समझना matter करता है, क्योंकि एक को दूसरे का substitute treat करना या unnecessary certification पर money waste करता है या card brands की penalties expose कर देता है। यह article explain करता है हर framework actually क्या require करता है, कहां overlap होते हैं, और साथ चलाना separately चलाने से less cost कैसे करता है।\nISO 27001: information security manage करने का governance framework #ISO/IEC 27001 define करता है organisation information security कैसे manage करता है, business चाहे कुछ भी हो। Core है information security management system (ISMS): documented cycle risk assessment, control selection, operation, measurement, improvement का।\nदो characteristics define करते हैं:\nRisk-based है। Standard नहीं बताता कौन सी firewall buy करें या patch कितनी बार। Require करता है risks identify करो, Annex A catalogue (और उससे beyond) के controls decide करो उन्हें address करते हैं, और decisions justify करो। दो organisations valid certificates hold कर सकते हैं जबकि control sets बहुत different run रहे हों, क्योंकि risks differ करते हैं।\nAccreditation bodies certify करते हैं। Certification accredited certification body issue करता है Stage 1 और Stage 2 audit follow करके। Certify होने पर three-year cycle में enter होते हो annual surveillance audits, फिर recertification. Certificate internationally recognised है, procurement teams इसीलिए love करती हैं: dozens vendor-risk questionnaire lines एक PDF से answer हो जाती हैं।\nFlexibility का trade-off abstraction है। ISO 27001 certificate partner को बताता है security systematically manage करते हो। यह नहीं बताता specific technical safeguard defined strength पर exists.\nPCI DSS: cardholder data की prescriptive operational requirements #PCI DSS एक purpose के लिए exists: payment card data protect करना। Card brands (Visa, Mastercard, Amex, JCB, UnionPay others) PCI Security Standards Council के through publish करते हैं, compliance acquiring banks और payment processors के through contractually enforce होती है।\nCharacter ISO 27001 का nearly opposite:\nPrescriptive है। Current version v4.x twelve families में concrete requirements spell करती है: network security controls, secure system configurations, stored account data protection, encryption transit over public networks, malware defences, access control, physical security, logging monitoring, regular security testing. ISO कहे \u0026ldquo;manage the risk of unauthorised access,\u0026rdquo; PCI कहती है \u0026ldquo;render all systems untrusted for authentication at 15 minutes of inactivity\u0026rdquo; या exact testing intervals specify करती है।\nCardholder data environment (CDE) scoped है। सब कुछ defining से start होता है card data कहां lives, flows, connects. CDE से connected systems scope में; properly segmented away systems may not. Scope reduction इसलिए most PCI programmes की highest-value activity है: fewer in-scope systems means less evidence, fewer assessment hours, lower ongoing cost.\nValidation annual और role-specific. Transaction volume और card brand rules depend करके, organisation validate करती है Report on Compliance (ROC) से signed by Qualified Security Assessor, या Self-Assessment Questionnaire supported by quarterly ASV vulnerability scans. ISO sense में \u0026ldquo;certificate\u0026rdquo; नहीं: point in time से tied attestation of compliance है।\nSide by side # Dimension ISO 27001 PCI DSS Purpose Manage information security risk organisation-wide Protect payment card data specifically Approach Risk-based, control selection justified by assessment Prescriptive, explicit technical and process requirements Applies to Any organisation, any data type Any entity that stores, processes or transmits card data Validation Certificate from accredited body, 3-year cycle, surveillance audits Annual ROC or SAQ, quarterly scans, enforced via contracts with acquirers Scope Whole ISMS, boundary defined by the organisation Cardholder data environment, defined by data flow Consequence of failure Loss of certificate, contractual damage Fines passed through acquiring banks, loss of card acceptance Overlap कहां होता है #Different philosophies के बावजूद underlying work का large share common है। दोनों frameworks require करते हैं:\nAccess control with least privilege और unique identification Sensitive data की encryption transit में, और stored secrets की Logging, monitoring, time synchronisation Vulnerability management और patching discipline Sensitive environments की segmentation Security awareness और documented policies review cycles संग Incident response planning और testing Practice में मतलब: एक बार well-built control usually दोनों auditors satisfy करता है, provided deliberately map करो। Struggle करने वाले organisations वे हैं जो controls twice build करते, per auditor एक बार, क्योंकि nobody maintained mapping frameworks के बीच।\nदोनों चलाने का practical way #Thai fintech या regional business cards लेकर enterprise clients pursue करते हुए, sequence जो work करती है:\nGovernance anchor ISO 27001 पर। ISMS, risk register, policy set, management review rhythm build करें। यह operating system बनता है बाकी सब का। PCI DSS overlay CDE पर। Scope tightly define करें, prescriptive requirements apply करें boundary के अंदर, document mapping from each PCI requirement back to ISMS controls. Evidence pipeline share करें। One logging platform, one vulnerability management process, one access review calendar feeding both programmes. Assessments verification exercises ban जाती हैं projects नहीं। दोनों calendars के against validate करें। ISO surveillance audits और PCI annual attestation year में different points land करते हैं plan करो तो; spacing use करें findings fix करने के लिए अगला आने से पहले। ऐसे करने पर existing ISO 27001 programme में PCI DSS add करने की marginal cost, या vice versa, either scratch से building की cost से far below है। Badly done, twice pay करते हो gaps still हैं।\nTo कौन सी चाहिए? #Two questions पूछें। Payment card data touch करते हो? Then PCI DSS applies, full stop: optional नहीं है, acquirer inconvenient moments पर writing में confirm कराएगा। Enterprise customers, banks regulators expect demonstrable security governance? Then ISO 27001 entire category हटा देती है procurement friction की।\nMost organisations payments में eventually both need करते हैं। Good news reinforce करते हैं: ISO management discipline देती है, PCI operational depth देती है जहां money moves।\nNot sure आपको ISO चाहिए, PCI, या दोनों, और actual scope क्या applies? सीधी समझ-जांच के लिए संपर्क करें: LINE (@PureSecurity) या email (hello@puresecurity.com). Active QSA practice के रूप में हम deliver करते हैं PCI DSS gap assessments और QSA audits alongside regulatory compliance advisory, combined programme mapping समेत ताकि एक control set से दोनों frameworks satisfy हों। या अपनी specific situation talk करने के लिए Engineering \u0026amp; Scoping Session schedule करें।\n","date":"19 फ़रवरी 2025","permalink":"https://puresecurity.com/hi/posts/iso-27001-vs-pci-dss/","section":"सुरक्षा विश्लेषण एवं तकनीकी सलाह","summary":"","title":"ISO 27001 बनाम PCI DSS: आपके व्यवसाय को कौन सा फ्रेमवर्क चाहिए?"},{"content":"अगर मैं ऐसे organisation के लिए exactly एक architectural change choose कर सकता जो breach risk और security costs दोनों कम करना चाहता है, तो वह नया product या platform नहीं होगा। Network segmentation होगा। मेरे पापस में कोई दूसरा control नहीं जो आपकी दो सबसे बड़ी problems को same money में कम करता है।\nReason simple है। Almost हर expensive security problem की एक root cause share करती है: flat networks छोटी problems को बड़ी बना देते हैं। Segmentation वह link cut करती है। वह contain करती है कि first mistake के बाद attacker कितना reach कर सकता है, compliance frameworks जिन systems की परवाह करते हैं उन्हें सिकोड़ती है, और unmanageable sprawl को कुछ ऐसा बदल देती है जिसे छोटी team actually समझ सकती है।\nFlat networks चुपचाप क्यों fail होते हैं #Flat network वह है जहां most systems most दूसरे systems से बात कर सकते हैं। Networks default में ऐसे ही खत्म होते हैं, क्योंकि flatness convenient है: नए server को database चाहिए तो negotiate करने को firewall rules नहीं, developer के laptop को test system चाहिए तो update करने को कुछ नहीं।\nCost बाद में आती है। Real intrusions actually कैसे progress करती हैं, consider करें। Initial foothold usually minor होता है: laptop पर phished credential, vulnerable VPN appliance, internet-facing management port वाला forgotten test server. अपने आप में उस foothold की worth कम है। Breaches को expensive lateral movement बनाता है: पहले compromised machine से attacker network explore करता है, credentials harvest करता है, उन servers तक पहुंचता है जो user device से reachable होने के लिए never meant नहीं थे, और escalate करता है जब तक valuable कुछ hold कर ले।\nFlat networks उस journey का हर step free कर देते हैं। Segmented networks हर step को attacker के लिए visible effort, time और noise की cost देते हैं। Penetration testers बताएंगे difference dramatic है: flat environment में हम routinely days में एक laptop से domain-wide compromise तक पहुंच जाते हैं; well-designed segments के against वही engagement पहले hop पर stall हो जाती है और वहीं रहती है।\nSegmentation क्या buy करती है #1. Initial breach impact limit करती है #Zones enforced boundaries से separated हों, तो user workstation compromise payment systems, domain controllers या industrial controls तक access grant नहीं करता। Attacker एक segment hold करता है, business नहीं। यह afternoon में recover होने वाले incident और breach announcement का difference है।\n2. Lateral movement रोकती है #Workloads के बीच east-west traffic rare, purposeful और observed होनी चाहिए। Most environments में वह इनमें से कुछ भी नहीं है। Segmenting का मतलब है कहीं भी land करने वाले attacker को open corridors की जगह dead ends मिलते हैं, और paths जो exist करनी चाहिए वे monitor करने लायक narrow हैं।\n3. Compliance scope सिकोड़ती है #यहीं cost reduction concrete होती है। PCI DSS cardholder data environment (CDE) और उससे connected हर चीज़ पर apply होती है। Proper segmentation, penetration testing verified के साथ, CDE hundreds की जगह handful systems हो सकती है। In-scope systems कम means evidence collection कम, assessment hours कम, annual validation cheaper, और patched और monitored रखने की surface छोटी। ISO 27001 risk treatment और containment वाली किसी भी regulator conversation के लिए same logic benefit देती है।\nहमने assessments देखे हैं जो purely effort में half हो गईं क्योंकि client पहले segmentation project complete कर चुका था। Segmentation work usually उस assessment savings के एक साल से less cost करती है जो वह create करती है।\n4. Network manageable बनाती है #Perhaps least appreciated फायदा: segmented networks knowable हैं। Traffic flows documented paths तक constrained हों, तो anomalies stand out करते हैं। Workload अचानक database server तक पहुंचे जिससे वह कभी बात नहीं करती थी, तो या incident है या misconfiguration, और दोनों attention deserve करते हैं। Flat network में वही signal noise में drown हो जाता है, क्योंकि सब सबसे बात करते हैं हर समय। Segmentation ही monitoring meaningful बनाती है।\nDesign principles जो टिकते हैं #अच्छी segmentation architecture है, appliance shopping नहीं। Matter करने वाले principles:\nBoxes से नहीं, data से start करें। Identify करें sensitive data कहां lives और flows करता है: cardholder data, credentials, personal information, financial records. Zones protection चाहने वाली चीज़ों के around form होती हैं, पिछले साल के diagram के around नहीं।\nTiers trust और function से define करें। Most organisations के लिए practical baseline:\ngraph TD I[Internet] --\u003e DMZ[DMZ / edge services] U[User networks] --\u003e APP[Application tier] DMZ --\u003e APP APP --\u003e DB[(Data tier:\ndatabases, CDE, secrets)] MGMT[Management network] -.-\u003e|admin access only| APP MGMT -.-\u003e DB U -.-\u003e|no direct access| DB style DB stroke:#EF4444,stroke-width:2px style MGMT stroke:#0EA5E9,stroke-width:2px Internet-facing services, user devices, application tier, data tier, और out-of-band management network. हर boundary की explicit allow-list; बाकी सब denied.\nDefault deny, फिर purposefully add करें। Zones के बीच हर permitted flow का owner हो और कहीं written reason हो। अगर कोई नहीं बता सकता rule क्यों exist करता है, वह exploit होने का wait करता finding है।\nCloud के अंदर भी segment करें। Security groups, VPCs और service policies segmentation ही हैं; cloud platforms बस differently implement करते हैं। Same discipline apply होती है: production non-production से isolated, databases internet से unreachable, admin planes separate paths पर।\nSegments test करें, assume न करें। Segmentation तभी counts जब attack के under hold करे। PCI DSS specifically standard को penetration testing require करती है जो isolation verify करे annually कम से कम और major changes के बाद। Penetration test जो हर zone से lateral movement attempt करे बताता है design work करती है या diagram में अच्छी लगती है।\nवहां पहुंचने का realistic path #कोई live network weekend में re-architect नहीं करता। Sequence जो work करती है:\nDiscover. Several weeks actual traffic flows map करें। Real networks documentation से everywhere differ करते हैं, always. Declare. Target zones define करें और लिखें कौन से flows हर boundary cross करेंगे। उस list पर business sign-off लें। Crown jewels पहले contain करें। Payment systems, domain infrastructure और sensitive data stores fence off करें cosmetic कुछ करने से पहले। Gradually migrate करें। Systems waves में zones में move करें, कुछ भी internet-facing से शुरू। Breakage low-stakes areas में fix करें जब lessons cheap हों। Verify और maintain करें। Boundaries annually test करें, rules quarterly review करें, और undocumented cross-zone flow को incident treat करें जब तक proven otherwise न हो। Most organisations steady work के one-two quarters में defensible baseline तक पहुंचते हैं, और earlier phases reduced audit scope के through immediately pay for themselves।\nBottom line #Security spending usually trade-off involve करती है: risk कम करो या cost। Network segmentation standing exception है। वह successful breach attempts का damage cap करती है, attackers को वह lateral movement starve करती है जो incidents expensive बनाती है, हर framework जिसे आप answer करते हो उसका scope सिकोड़ती है, और ऐसा network produce करती है जिस पर team reason कर सकती है। Argue करने लायक कोई second place नहीं है।\nसोच रहे हैं आपका current network intrusion contain करेगा या फैलाएगा? सीधी समझ-जांच के लिए संपर्क करें: LINE (@PureSecurity) या email (hello@puresecurity.com). हमारा Configuration \u0026amp; Architecture Assessment आपके real traffic flows map करता है और ऐसी segmentation roadmap design करता है जिसे team execute कर सके, और हमारे penetration testing segments actually hold करते हैं verify करते हैं। या कहां से शुरू करें बात करने के लिए Engineering \u0026amp; Scoping Session schedule करें।\n","date":"15 जनवरी 2025","permalink":"https://puresecurity.com/hi/posts/network-segmentation-design/","section":"सुरक्षा विश्लेषण एवं तकनीकी सलाह","summary":"","title":"नेटवर्क विभाजन डिज़ाइन: जोखिम और लागत एक साथ कम करें"},{"content":"जब बोर्ड के सदस्यों के सामने त्रैमासिक सुरक्षा रिपोर्ट प्रस्तुत की जाती है, तो वे एक स्वाभाविक प्रश्न पूछते हैं: हमें इस जानकारी के साथ क्या करना चाहिए? अक्सर, इसका ईमानदार उत्तर होता है: कुछ भी नहीं। रिपोर्ट में ब्लॉक किए गए ईमेल की संख्या, प्रशिक्षण पूरा करने का प्रतिशत और किसी विक्रेता से ली गई सामान्य खतरे की स्लाइड शामिल होती है। यह गतिविधि रिपोर्टिंग है, सुरक्षा का वास्तविक आश्वासन नहीं, और यह निदेशकों को वहीं छोड़ देती है जहाँ से उन्होंने शुरुआत की थी: यह निर्णय लेने में असमर्थ कि संगठन वास्तव में लचीला है या केवल व्यस्त है।\nजो मेट्रिक्स वास्तव में बोर्ड के लिए महत्वपूर्ण होते हैं, उनमें एक साझा विशेषता होती है। वे दबाव में क्षमता को मापते हैं, खर्च किए गए प्रयास को नहीं। बोर्ड को यह जानने की आवश्यकता नहीं है कि पिछले महीने कितने फ़िशिंग ईमेल फ़िल्टर किए गए थे। उन्हें यह जानने की आवश्यकता है कि यदि कल रैनसमवेयर का हमला होता है, तो क्या व्यवसाय उस पूरे सप्ताह जीवित और चालू रह पाएगा।\nअधिकांश सुरक्षा रिपोर्टिंग क्यों विफल हो जाती है #सुरक्षा टीमें आमतौर पर वही रिपोर्ट करती हैं जो उनके उपकरण आसानी से गिनते हैं, क्योंकि उसे निकालना सबसे आसान होता है। इसका परिणाम ऐसे डैशबोर्ड के रूप में सामने आता है जो लगातार बढ़ती संख्याओं से भरे होते हैं लेकिन जिनका कोई वास्तविक अर्थ नहीं होता:\nब्लॉक किए गए खतरे। एक बड़ी संख्या का मुख्य अर्थ केवल यह है कि आपको अधिक स्पैम प्राप्त होता है। हर मेल प्लेटफ़ॉर्म लाखों संदेशों को ब्लॉक करता है; महत्वपूर्ण प्रश्न यह है कि क्या अंदर पहुंच गया, और कोई भी उपकरण ईमानदारी से उसकी गिनती नहीं करता। प्रशिक्षण पूर्णता दर। पूर्णता दर केवल उपस्थिति को मापती है, कर्मचारियों के व्यावहारिक व्यवहार को नहीं। कोई संगठन 100% पूर्णता दर प्राप्त कर सकता है और फिर भी अगले ही सप्ताह एक वास्तविक सोशल इंजीनियरिंग परीक्षण में विफल हो सकता है। हजारों में कमजोरियों की संख्या। संदर्भ और वास्तविक जोखिम के बिना कच्ची संख्याएं अर्थहीन हैं। आंतरिक परीक्षण प्रणालियों पर दस हजार कम-गंभीरता वाली कमजोरियां इंटरनेट-फेसिंग भुगतान बुनियादी ढांचे पर दो महत्वपूर्ण कमजोरियों की तुलना में बहुत कम मायने रखती हैं। अलर्ट वॉल्यूम। अधिक अलर्ट का अर्थ अधिक शोर है, अधिक सुरक्षा नहीं। यदि कुछ भी है, तो धीमी छंटाई (triage) के साथ उच्च अलर्ट संख्या तैयारी के ठीक विपरीत स्थिति का संकेत देती है। इनमें से कोई भी प्रश्न किसी निदेशक के वास्तविक प्रत्ययी (fiduciary) प्रश्न का उत्तर नहीं देता: क्या हम तैयार हैं, और हमें यह कैसे पता चलेगा?\nआंकड़ों में वास्तविक लचीलापन कैसा दिखता है #बोर्ड परिणामों का संचालन और शासन करते हैं: व्यावसायिक निरंतरता, कानूनी जोखिम और प्रतिष्ठा। बोर्ड के समय के लायक मेट्रिक्स सीधे इन्हीं को मापते हैं।\nडिटेक्शन और रिस्पॉन्स की गति #समझौते और रोकथाम के बीच कितना समय लगता है? औसत पहचान समय (MTTD) और औसत प्रतिक्रिया समय (MTTR), जिन्हें वास्तविक घटनाओं और परीक्षण किए गए परिदृश्यों दोनों से मापा जाता है, सुरक्षा के लिए एक महत्वपूर्ण स्वास्थ्य संकेत के सबसे करीब हैं। उद्योग अनुसंधान लगातार डेटा उल्लंघन की लागत को रोकथाम की गति से जोड़ता है: जो संगठन हफ्तों के भीतर नियंत्रण पा लेते हैं वे महीनों लगाने वालों की तुलना में बहुत कम भुगतान करते हैं। यदि ये आंकड़े ज्ञात नहीं हैं, तो यह स्वयं बोर्ड के लिए एक महत्वपूर्ण निष्कर्ष है।\nपुनर्प्राप्ति का प्रमाण (Recovery Proof) #जिन बैकअप्स को कभी रीस्टोर नहीं किया गया, वे केवल उम्मीदें हैं, सुरक्षा नियंत्रण नहीं। वह मीट्रिक जो वास्तव में मायने रखता है: हमने पिछली बार बैकअप से पूर्ण उत्पादन सेवा कब रीस्टोर की थी, और इसमें कितना समय लगा था? उन प्रणालियों के लिए अपरिवर्तनीय (immutable) बैकअप कवरेज जोड़ें जिन्हें रैनसमवेयर पहले लक्षित करेगा। सहमत रिकवरी टाइम ऑब्जेक्टिव (RTO) के भीतर एक परीक्षण किया गया रीस्टोर किसी भी खतरे के आंकड़े की तुलना में एक निदेशक के लिए अधिक मूल्यवान है, क्योंकि यह प्रत्यक्ष प्रमाण है कि व्यवसाय विनाशकारी हमले से बच सकता है।\nपूर्वाभ्यास और उसके परिणाम #कार्यकारी टीम ने पिछली बार साइबर संकट का पूर्वाभ्यास कब किया था, और इसने क्या कमियां उजागर कीं? टेबलटॉप अभ्यास ठोस निष्कर्ष उत्पन्न करते हैं: निर्णय प्राधिकरण की कमी, अनुपलब्ध विक्रेता, अस्पष्ट ग्राहक संचार स्वामित्व। इन्हें उसी तरह ट्रैक करें जैसे आप ऑडिट निष्कर्षों को ट्रैक करते हैं: पहचाना गया, सौंपा गया, और बंद किया गया। एक बोर्ड जो अभ्यास निष्कर्षों को समय पर बंद होते देखता है, वह जानता है कि संगठन हमलावरों के विकसित होने की तुलना में तेजी से सीखता है।\nएक्सपोज़र जो वास्तव में मायने रखता है #कमजोरियों की कच्ची संख्या को परिणाम से जुड़े जोखिम मेट्रिक्स से बदलें:\nइंटरनेट-फेसिंग सिस्टम पर गंभीर या उच्च कमजोरियां, जिन्हें SLA के भीतर पैच किया गया: प्रतिशत और प्रवृत्ति। किसी भी राजस्व-उत्पादक प्रणाली पर सबसे पुरानी अनपैच्ड क्रिटिकल भेद्यता की आयु। MFA और जस्ट-इन-टाइम एक्सेस द्वारा कवर किए गए विशेषाधिकार प्राप्त एडमिन खातों का प्रतिशत। ये संख्याएं सीधे उल्लंघन की संभावना से जुड़ती हैं, जो उन प्रमुख समाचार सुर्खियों से जुड़ती हैं जिनके प्रबंधन के लिए निदेशक जिम्मेदार हैं।\nथर्ड-पार्टी एक्सपोज़र #कई संगठनों के लिए, अगला डेटा उल्लंघन किसी विक्रेता या भागीदार के माध्यम से आता है। बोर्ड को यह देखना चाहिए: कितने महत्वपूर्ण आपूर्तिकर्ताओं का मूल्यांकन किया गया है, कितने वर्तमान मूल्यांकन अतिदेय (past due) हैं, और क्या प्रत्येक महत्वपूर्ण प्रदाता के साथ संविदात्मक घटना अधिसूचना शर्तें मौजूद हैं। यह सीधे मौजूदा विक्रेता-जोखिम शासन पर मैप होता है जिसे निदेशक पहले से समझते हैं।\nव्यवसाय को नकारात्मक सुर्खियों से दूर रखना #निदेशक अक्सर अपने सुरक्षा लक्ष्य का सीधा वर्णन करते हैं: अगली ब्रीच स्टोरी न बनें। वह लक्ष्य मापने योग्य घटकों में विभाजित होता है, जिनमें से किसी की व्याख्या करने के लिए तकनीकी प्रवाह की आवश्यकता नहीं होती:\nबोर्ड का प्राथमिक उद्देश्य इसे सिद्ध करने वाला मीट्रिक हम घुसपैठ की त्वरित पहचान करेंगे MTTD रुझान; महत्वपूर्ण प्रणालियों का निगरानी कवरेज बड़े नुकसान से पहले इसे नियंत्रित करेंगे MTTR रुझान; परीक्षणों में लेटरल मूवमेंट पर रोकथाम हम रैनसमवेयर हमले में जीवित रहेंगे परीक्षण किया गया रीस्टोर समय बनाम RTO; इम्यूटेबल बैकअप कवरेज हम कानूनी दायित्वों को पूरा करेंगे ब्रीच अधिसूचना प्रक्रिया का परीक्षण; नियामक दायित्वों का संरेखण हमारे साझेदार हम पर भरोसा करते हैं महत्वपूर्ण विक्रेता मूल्यांकन अद्यतन; वैध फ्रेमवर्क सत्यापन केवल इस तालिका, रुझानों और अपवादों से युक्त एक त्रैमासिक रिपोर्ट किसी बोर्ड को उपकरण सांख्यिकी की चालीस स्लाइडों की तुलना में अधिक वास्तविक आश्वासन देती है।\nईमानदार आंकड़े कैसे प्राप्त करें #इन मेट्रिक्स के लिए इंजीनियरिंग ईमानदारी की आवश्यकता होती है, यही कारण है कि वे दुर्लभ हैं:\nअनुमानों के बजाय अभ्यासों के माध्यम से मापें। रीस्टोर का समय वास्तविक रीस्टोर परीक्षण से आता है। प्रतिक्रिया का समय सिम्युलेटेड घुसपैठ से आता है। यदि किसी ने परीक्षण नहीं चलाया है, तो \u0026ldquo;अज्ञात\u0026rdquo; रिपोर्ट करें, जो अपने आप में बोर्ड के लिए कार्रवाई योग्य जानकारी है। स्नैपशॉट के बजाय रुझानों की रिपोर्ट करें। एकल मान हेरफेर को आमंत्रित करते हैं; प्रवृत्तियां बताती हैं कि क्या सुरक्षा कार्यक्रम में वास्तविक सुधार हो रहा है। प्रत्येक लाल संख्या को निर्णय अनुरोध के साथ जोड़ें। बोर्ड संसाधन आवंटित करके शासन करते हैं। \u0026ldquo;रीस्टोर परीक्षण हमारे RTO में विफल रहता है; हमें छह सप्ताह के लिए दो इंजीनियरों की आवश्यकता है\u0026rdquo; एक प्रभावी शासन वाक्य है। \u0026ldquo;जोखिम उच्च बना हुआ है\u0026rdquo; शासन वाक्य नहीं है। इसे संक्षिप्त रखें। रुझानों के साथ मेट्रिक्स का एक पृष्ठ, और अनुरोधित निर्णयों का एक पृष्ठ। यदि बोर्ड पैक को पूर्व-जानकारी ब्रीफिंग की आवश्यकता है, तो यह बहुत जटिल है। इस शैली की रिपोर्टिंग अपनाने वाले संगठन आमतौर पर एक उपयोगी बात खोजते हैं: बातचीत \u0026ldquo;क्या आईटी पर्याप्त खर्च कर रहा है?\u0026rdquo; से हटकर रिकवरी उद्देश्यों, कर्मचारियों और तीसरे पक्ष के जोखिम के बारे में विशिष्ट, निर्णय योग्य प्रश्नों पर स्थानांतरित हो जाती है। यह बदलाव ही वास्तविक कॉर्पोरेट शासन का अनुभव कराता है।\nक्या आप अपनी बोर्ड रिपोर्टिंग को वास्तविक लचीलेपन के मेट्रिक्स पर केंद्रित करना चाहते हैं? सीधे तकनीकी परामर्श के लिए संपर्क करें: ईमेल (hello@puresecurity.com) या LINE (@PureSecurity)। हमारी vCISO सलाहकार सेवा बोर्ड-स्तरीय रिपोर्टिंग बनाती है जिस पर निदेशक सीधे कार्रवाई कर सकते हैं, और हमारे साइबर संकट टेबलटॉप अभ्यास उन रिपोर्टों को सच्चा बनाने वाले पूर्वाभ्यास निष्कर्ष उत्पन्न करते हैं। या बातचीत शुरू करने के लिए इंजीनियरिंग एवं स्कोपिंग सत्र निर्धारित करें।\n","date":"18 दिसंबर 2024","permalink":"https://puresecurity.com/hi/posts/board-security-metrics/","section":"सुरक्षा विश्लेषण एवं तकनीकी सलाह","summary":"","title":"बोर्ड के लिए आवश्यक वास्तविक सुरक्षा मेट्रिक्स: व्यर्थ आंकड़ों से परे"},{"content":"Ransomware कोई गुजरने वाला trend नहीं है। वह एक industry है, और लाभदायक भी: criminal groups उसे sales teams, affiliate programmes, customer support desks और negotiated revenue splits के साथ चलाते हैं। वे अपनी capability में invest करते हैं क्योंकि वह reliably पैसा लौटाती है, जिसका मतलब है वे reinvest करते हैं, skilled developers hire करते हैं, और ज़्यादातर defenders के update करने से faster adapt करते हैं। Prevention matter करती है, लेकिन honest starting point यह है: मान लें कि एक दिन, सब कुछ होने के बावजूद, encryption payload आपके systems पर run होगा। Preparedness उस assumption के बाद शुरू होने वाली चीज़ है।\nयह article उस reality के दोनों halves cover करता है: ransomware outright रोकना इतना मुश्किल क्यों है, और modern, cloud-connected environments में preparedness वास्तव में कैसी दिखती है, backup strategies समेत जिन्हें attackers छू सकते हैं पर destroy नहीं।\nRansomware रोकना इतना मुश्किल क्यों है #Early ransomware opportunistic था: infected machine जहां तक पहुंच सके encrypt करो, कुछ सौ dollars मांगो। Modern model targeted और patient है। Groups phishing, exposed remote access या purchased credentials से access लेते हैं, फिर days या weeks तक चुपचाप अंदर move करते हैं, privileges escalate करते हैं, backups map करते हैं, और कुछ visible trigger करने से पहले data exfiltrate करते हैं।\nउस evolution ने दो problems बनाईं जिन्हें defenders simply buy नहीं कर सकते:\nDouble extortion backup escape hatch हटा देता है। Backup से restore पहले crisis खत्म कर देता था। अब stolen data pay करने से इनकार पर published या sold हो जाता है, इसलिए clean restore के बाद भी आप data breach, PDPA और equivalents के तहत regulatory notification duties, और public exposure face करते हैं। Backup necessary है; अब sufficient नहीं रहा।\nInitial foothold सिर्फ एक बार होना चाहिए। Defenders को हर phishing email, हर unpatched appliance, हर credential leak, हर third-party connection के against succeed करना पड़ता है। Attacker को किसी Tuesday एक success चाहिए। ऐसी asymmetries wishing से defender के favour में resolve नहीं होतीं।\nइसमें से कोई भी बात defence pointless नहीं कहती; वह hit होने की odds बदलती है। लेकिन hit का outcome वह नहीं बदल सकती। वह सिर्फ preparation बदलती है।\nइसका अनुभव वास्तव में कैसा होता है #Boards ransomware को technical event मानते हैं। जो organisations उसे झेल चुके हैं वे कुछ ऐसा describe करते हैं जो invoice वाली natural disaster के करीब है:\nWeeks of downtime. Pay करने से इनकार करने और अच्छे backups वाले organisations भी production services fully restore करने में routinely weeks लेते हैं, क्योंकि rebuilding sequenced, validated और planned से slow होती है। Costs from everywhere at once. Crisis rates पर incident response और forensics, emergency legal counsel, IT और operations में overtime, rebuilt hardware, daily compounding lost revenue, और बाद में regulatory investigations ऊपर से। Decisions under pressure without authority. Pay करने का decision कौन लेता है? Staff को कौन बताता है? Customers, regulators, journalists से कौन बात करता है? जिन companies ने ये questions rehearse नहीं किए वे इनके बुरे, slow और often public जवाब देते हैं। A long tail of distrust. Customers churn करते हैं, enterprise contracts invoke होते हैं, और incident आने वाले हर procurement conversation में years तक resurface होता है। यह shape समझना matter करता है क्योंकि नीचे हर preparedness measure directly इन costs में से एक कम करने पर map होता है।\nImmutable backups: वह control जो outcome बदल देता है #अगर एक single technical investment है जो ransomware को catastrophe से bad week में बदल दे, तो वह backups हैं जिन्हें attacker alter या delete नहीं कर सकता। Traditional backups इसमें exactly इसीलिए fail हुए कि वे reachable थे: domain credentials वाले attackers routinely backup jobs पहले delete या encrypt करते हैं, फिर ऐसे organisation पर main event trigger करते हैं जिसके पास कुछ बचा नहीं।\nModern object storage इसे immutability से solve करता है:\nObject Lock / WORM storage backups उस form में write करता है जिसे retention period के लिए modify या delete नहीं किया जा सकता, किसी के द्वारा भी, आपके अपने administrators समेत। AWS S3 Object Lock, Azure immutable blob storage और दूसरे clouds की comparable offerings यही pattern implement करती हैं। Retention periods survival की window बनाते हैं। Immutability windows ऐसे set करें कि attacker जो आज destroy करे, उसके access से पहले के versions lock expire होने तक survive करें। Cloud-specific design detail यहीं matter करता है: protected copies पर कोई भी write या delete access restrict करें जब तक files retention से age out न हों। सिर्फ attacker accounts नहीं: all accounts. Intrusion के दौरान compromise हुए credentials आपके अपने होते हैं, इसलिए protection उनके against भी hold करनी चाहिए। Backup identity को entirely separate रखें। Backup infrastructure dedicated credentials, separate authentication domains और production user environments से unreachable network paths use करे। अगर वही admin account production और backups दोनों manage करता है, immutability अकेली सारा काम कर रही है, और उसे help deserving है। Test restores schedule पर करें। Untested backup hypothesis है। Full production service regularly restore करें, time करें, और test जो reveal करे वह low stakes पर fix करें। Backups से आगे access restrict करना #Immutability recovery path protect करती है। Access को restrict करने का वही principle जब तक trust earned न हो, elsewhere भी apply होता है:\nPrivileged access just-in-time. Standing administrative rights का मतलब है intruder उन्हें inherit करता है। Approval और expiry के साथ elevation सिकोड़ती है कि कोई single compromised account क्या unlock करता है। Staged recovery environments. Clean management enclave, offline built या verified, जिससे rebuilds perform होती हैं। Compromised management plane से rebuilding attacker reinstall कराती है। Critical segments का segregation. Payment systems, domain controllers और industrial controls enforced boundaries के पीछे limit करते हैं कि एक encrypted workstation cascade में क्या बदल सकता है। Preparedness checklist #इसे उस sequence में लें जिसे छोटी team दो quarters में execute कर सकती है:\nBackups first: critical systems की immutable object-lock copies, separate backup identity, documented retention, first full restore test. Decision rehearse करें: cyber crisis tabletop exercise payment question, notification duties और communication roles cover करता है। Found gaps अब cheap हैं, later expensive. Response capacity advance में establish करें: DFIR retainer का मतलब है forensics और containment agreed terms के तहत hours में शुरू, live crisis के दौरान procurement से शुरू होने के बजाय। Privileged standing access सिकोड़ें identity platforms में। Boundaries annually verify करें: segmentation और isolation claims penetration testing से tested, assumed नहीं। Preparedness ransomware impossible नहीं बनाती। वह existential event को costly पर survivable में convert करती है, और इन दोनों outcomes का difference almost entirely incident शुरू होने से पहले decide हो जाता है।\nक्या आप जानना चाहेंगे कि आपका संगठन अगले हफ्ते ransomware survive करेगा या नहीं? सीधी समझ-जांच के लिए संपर्क करें: LINE (@PureSecurity) या email (hello@puresecurity.com). हमारा DFIR retainer response capacity जरूरत से पहले place में डालता है, और हमारा Configuration \u0026amp; Architecture Assessment आपकी backup architecture, privilege model और segmentation को exactly इस scenario के against review करता है। या checklist अपनी team के साथ plan करने के लिए Engineering \u0026amp; Scoping Session schedule करें।\n","date":"20 नवंबर 2024","permalink":"https://puresecurity.com/hi/posts/ransomware-preparedness-apac/","section":"सुरक्षा विश्लेषण एवं तकनीकी सलाह","summary":"","title":"APAC में रैनसमवेयर तत्परता: मान लें कि हमला अंदर घुस जाएगा"},{"content":"Zero trust की marketing में एक दिक्कत है। यह term platform pitches और multi-year transformation programs के साथ आती है, जिससे यह impression बनता है कि zero trust adopt करने का मतलब है पूरी identity, network और endpoint estate को एक ही heroic effort में बदल देना। इस तरह कोशिश करने वाले लगभग हर संगठन के प्रोग्राम अटक जाते हैं: प्रोजेक्ट fund करने के लिए बहुत बड़ा, चलाने के लिए बहुत disruptive, और steering committee में चुपचाप मर जाता है।\nजो संगठन वास्तव में वहां पहुंचते हैं, वे कुछ कम glamorous करते हैं। वे zero trust architecture (ZTA) को product purchase नहीं, travel direction मानते हैं, और ऐसे छोटे, consistent कदमों में उसकी ओर बढ़ते हैं जिनमें से हर कदम standalone value देता है। लगभग हर environment में उनमें से पहला कदम एक ही है: वे legacy access protocols हटाते हैं जो चुपचाप आपके हर modern control को खोखला कर रहे होते हैं।\nZero trust असल में क्या मांगता है #Branding हटाकर core idea simple है: access देना बंद करें इस आधार पर कि request कहां से आई है, और शुरू करें इस आधार पर कि request क्या है और यह कौन कर रहा है, हर बार verified.\nTraditional security network interior पर भरोसा करती थी। Perimeter के अंदर मतलब trusted था, इसलिए corporate LAN पर, या बाद में VPN पर, laptop बहुत कुछ minimal re-checking के साथ छू सकता था। Zero trust वह assumption उलट देता है:\nExplicitly verify. हर request identity, device health और context से authenticate और authorise होती है, network location चाहे जो भी हो। Least privilege. Users और workloads को न्यूनतम access मिलता है, जहां संभव हो time-scoped. Assume breach. Design ऐसे करें जैसे attacker पहले से अंदर है, और किसी single compromise से खुलने वाली चीज़ों को सीमित करें। आखिरी principle ठीक इसी बात से जुड़ता है कि legacy protocols natural first target क्यों हैं।\nकदम एक: Legacy protocols को घर से निकालें #Legacy access protocols anti-zero-trust हैं। वे modern identity thinking से पहले के हैं, और उनकी assumptions ऐसी हैं जिन्हें कोई नया tooling fix नहीं कर सकता:\nSMBv1 और unpatched file-sharing dialects, decades पुराने और neglect से अब भी enabled, जिनका इस्तेमाल attackers entry और lateral movement दोनों के लिए करते हैं। NTLMv1 और अन्य weak authentication schemes, जो modern verification support नहीं करते और routinely relayed या cracked हो जाते हैं। Telnet और unencrypted FTP, उन networks में credentials cleartext में भेजते हुए जिन्हें आप segmented कहते हैं। HTTP basic authentication और unsigned LDAP binds, reusable passwords उन लोगों को expose करते हुए जो traffic observe करने की position में हैं। Legacy mail retrieval protocols (unencrypted POP3/IMAP), वह MFA bypass करते हुए जो आप बाकी हर जगह enforce करते हैं। इनमें से हर एक एक standing invitation है जो कहती है: 1990s के credentials लेकर आओ, हम इन्हें valid मानेंगे। जब तक ये enabled हैं, ये identity checks, device posture checks और conditional access policies के चारों ओर shortcuts बने रहते हैं। ऐसे protocols पर जिनकी पूरी design location-based trust मानती है, आप zero trust architecture build नहीं कर सकते।\nRemoval वह rare security project भी है जिसका payoff near-immediate है और cost low. ज़्यादातर environments logging के ज़रिए, guesswork से नहीं, पाते हैं कि हर legacy protocol पर systems या workflows की एक छोटी संख्या depend करती है: पुराना printer fleet, किसी supplier का integration, कोई भूला हुआ application. हर dependency का एक छोटा remediation plan बनता है; बाकी सब switch off हो जाता है। Focus के एक quarter में typically exposure का majority खत्म हो जाता है।\nफिर बाहर की ओर consistently upgrade करें #Legacy floor clear होने के बाद बचा सफर overlapping upgrades की sequence है। इनमें से किसी को big bang नहीं चाहिए, और हर एक अगले को आसान बनाता है:\ngraph LR A[Remove legacy\nprotocols] --\u003e B[MFA everywhere:\nusers \u0026 admins] B --\u003e C[Identity-based access:\nreplace implicit trust] C --\u003e D[Device posture \u0026\nconditional access] D --\u003e E[Per-application micro-segmentation] style B stroke:#10B981,stroke-width:2px style E stroke:#0EA5E9,stroke-width:2px Pehle MFA coverage, especially privileged accounts. Sequence में यह highest value-per-dollar control है, और identity foundation establish करता है जिस पर बाकी सब बनता है। Administrators के लिए जहां feasible हो phishing-resistant methods. Implicit network trust को explicit grants से बदलें। Remote access को flat VPNs से per-application access की ओर ले जाएं जो identity द्वारा brokered हो। हर migrated application stolen laptop का blast radius सिकोड़ती है। Decisions में device health जोड़ें। Access identity से flow करने लगे, तो sensitive applications के लिए managed, patched devices require करें। Unhealthy devices को production data नहीं, quarantined paths मिलती हैं। Workloads progressively micro-segment करें। Sabse critical services से शुरू करें: payment systems, domain infrastructure, sensitive data stores. उनके callers explicitly allow-list करें। यह east-west traffic पर applied zero trust है, और इस blog पर पहले discussed segmentation discipline के साथ compound होता है। Instrument और iterate करें। हर access decision log करें, denials को false positives के लिए review करें, और scope उस cadence पर expand करें जिसे आपकी teams absorb कर सकें। Consistency क्यों speed को हराती है #Zero trust programs का failure mode गलत technology चुनना नहीं; enthusiasm से शुरू करके बीच में रुक जाना है। Half-deployed architecture अक्सर none से भी बुरी होती है: दो access models parallel में चलने का मतलब maintain करने के दो rules sets, और users उसमें से जो ज्यादा झंझट वाला है, उसके around route कर लेते हैं।\nConsistent rollout इसलिए जीतता है:\nहर phase usable पर खत्म होता है। Users एक समय में एक change experience करते हैं, support channels तैयार, migration wall की जगह। Security gains जल्दी आते हैं और compound होते हैं। Legacy protocols हटाने का payoff तुरंत है; MFA का भी। आप कभी distant finish line का wait करते हुए unbuilt risk hold नहीं करते। Budget reality के contact में survive करता है। छोटे funded phases finance review बार-बार pass करते हैं; एक विशाल program आमतौर पर एक बार pass करता है और फिर cut हो जाता है। आपकी architecture knowledge इसके साथ बढ़ती है। Micro-segmentation तक पहुंचते-पहुंचते आपकी team identity upgrades और conditional access से गुजर चुकी होती है और अपने environment के real traffic patterns जानती है। Mid-sized organisations के लिए realistic timeline ऐसा दिखता है: legacy protocol removal एक-दो quarters में, universal MFA उसी के साथ, per-application access अगले दो-तीन quarters में, और progressive workload segmentation standing practice की तरह चलती रहती है। दो साल बाद, कभी \u0026ldquo;transformation\u0026rdquo; run किए बिना, आप ऊपर देखते हैं और पाते हैं कि आप उसे operate कर रहे हैं।\nक्या आप व्यावहारिक zero trust roadmap चाहते हैं जो आपके पास पहले से मौजूद चीज़ों से शुरू हो? सीधी समझ-जांच के लिए संपर्क करें: LINE (@PureSecurity) या email (hello@puresecurity.com). हमारा Configuration \u0026amp; Architecture Assessment आज आपके environment में छिपे legacy protocols और implicit-trust paths identify करता है, और हमारी vCISO advisory rollout को ऐसे fundable phases में sequence करती है जिन्हें आपकी team sustain कर सके। या Engineering \u0026amp; Scoping Session schedule करें और step one से शुरू करें।\n","date":"16 अक्टूबर 2024","permalink":"https://puresecurity.com/hi/posts/zero-trust-implementation/","section":"सुरक्षा विश्लेषण एवं तकनीकी सलाह","summary":"","title":"जीरो ट्रस्ट कार्यान्वयन: टिकने वाले छोटे कदमों से शुरुआत करें"},{"content":"अधिकांश संगठन अपने सर्वरों की रक्षा ऐसे करते हैं जैसे सर्वर ही असली कीमती चीज़ हों। उनकी इमेज बनाते हैं, बैकअप लेते हैं, घबराकर पैच करते हैं, और जब एक सर्वर खराब होता है या कंप्रोमाइज हो जाता है, तो उसे ठीक पहले जैसा था वैसा ही बहाल करने में घंटों डाल देते हैं। और उनका डेटा, जो वास्तव में अनमोल हिस्सा है, उन्हीं सर्वरों पर पड़ा रहता है, जितनी सुरक्षा सर्वर को नसीब हुई उतनी ही साथ लेकर।\nइस रिश्ते को उलट दें और सुरक्षा का एक बड़ा हिस्सा आसान हो जाता है। सिस्टम्स को डिस्पोजेबल मानें और डेटा को अनमोल। सर्वरों को कोड से बनाएं ताकि उन्हें दिनों में रीस्टोर करने के बजाय मिनटों में बदला जा सके। फिर असली सुरक्षा प्रयास वहां लगाएं जहां उसका हकदार है: डेटा पर। उसे पूरे जीवनचक्र में ट्रैक करें, जानबूझकर बैकअप लें, और तेजी से ऐसी जगह स्टोर करें जो प्रोसेसिंग करने वाले सिस्टम से ही अलग हो।\nसिस्टम जिन्हें आप दोबारा तैनात करते हैं, ठीक नहीं करते #पुराना मॉडल सर्वरों को पालतू जानवर (pets) की तरह देखता था। हर एक का नाम होता था, अपना व्यक्तित्व, और मैन्युअल फिक्स का इतिहास जिसे कोई पूरी तरह डॉक्यूमेंट नहीं कर पाया था। जब ऐसा pet-server मरता था, तो रिकवरी का मतलब था पुरातत्व की खुदाई: यादों, नोट्स और उम्मीद से सालों के जमा बदलावों को दोबारा जोड़ना।\nआधुनिक मॉडल सर्वरों को मवेशी (cattle) मानता है, DevOps वाले उस प्रसिद्ध वाक्यांश की तरह जो अब भी चलन में है। आप बीमार गाय को ठीक नहीं करते; आप उसे बदल देते हैं और आगे बढ़ जाते हैं। व्यावहारिक रूप से इसका मतलब है:\nInfrastructure as code. हर सर्वर, कंटेनर और कॉन्फ़िगरेशन declarative तरीके से परिभाषित होता है: प्लेटफॉर्म के लिए Terraform, होस्ट के लिए Ansible या cloud-init, वर्कलोड्स के लिए कंटेनर इमेज। चलता हुआ इंस्टेंस बस उस परिभाषा का एक रूप है, किसी दूसरे से अलग नहीं।\nImmutable deployment. सर्वरों में लॉग इन करके उन्हें बदलने या पैच करने के बजाय, आप नया वर्जन बनाते हैं, टेस्ट करते हैं, और पुराने इंस्टेंस को पूरी तरह बदलकर रोल आउट करते हैं। कुछ भी जमा नहीं होता। Configuration drift, यानी मैन्युअल बदलावों का वह चुपचाप जमा होता पहाड़ जो हर एनवायरनमेंट को अलग और असमझने योग्य बना देता है, निर्माण से ही असंभव हो जाता है।\nRedeployment replaces restoration. और यहां वह फायदा है जो लोगों को चौंकाता है: ठीक से बनी cattle-fleet को बैकअप की भी जरूरत नहीं पड़ती। अगर कोई सर्वर कंप्रोमाइज, corrupt या खोया हुआ है, तो आप उसे रीस्टोर नहीं करते। आप उसे कोड से मिनटों में दोबारा तैनात करते हैं, क्योंकि परिभाषा ही बैकअप है। रिकवरी की बातचीत बदलकर \u0026ldquo;इस मशीन को कैसे वापस लाएं?\u0026rdquo; से होकर \u0026ldquo;रिप्लेसमेंट कितनी जल्दी लॉन्च कर सकते हैं?\u0026rdquo; हो जाती है, जो घटना के दौरान होने वाली बातचीत में कहीं बेहतर है।\nयह रैनसमवेयर की सतह को भी नाटकीय रूप से सिकोड़ देता है। एन्क्रिप्शन तभी नुकसान करता है जब एन्क्रिप्ट हुई चीज़ को दोबारा बनाना मुश्किल हो। Git रिपॉजिटरी से बनी disposable मशीनें दोबारा बनाने में सस्ती होती हैं।\nसारा ध्यान डेटा की ओर मुड़ जाता है #एक बार सिस्टम disposable हो जाएं, तो सब कुछ जो अनुतोष्य (irreplaceable) है, डेटा में रहता है। इसे अपना अनुशासन चाहिए, और इसकी शुरुआत उस सवाल से होती है जिसका जवाब अधिकांश संगठनों ने कभी सटीक रूप से नहीं दिया: हमारे पास कौन सा डेटा है, वह कहां रहता है, कौन छूता है, और समय के साथ उसका क्या होता है?\nTrack data through its lifecycle. बनाया गया, प्रोसेस हुआ, कॉपी हुआ, आर्काइव हुआ, नष्ट हुआ: हर चरण ज्ञात और जानबूझकर होना चाहिए। Lifecycle tracking बार-बार फायदा देता है। यह बताता है कि आपके विनियामक दायित्व कहां लगते हैं, क्योंकि PDPA और इसी तरह के कानून मशीन का पीछा नहीं करते, डेटा का करते हैं। यह उन भूले हुए कॉपियों को बाहर लाता है जिनका हिसाब किसी के पास नहीं होता, और ब्रीच वहीं से होते हैं। और यह बताता है कि आज क्या डिलीट किया जा सकता है, जो अक्सर उपलब्ध सबसे सस्ता जोखिम-कटौती उपाय है: डेटा जो मौजूद नहीं है, वह लीक नहीं हो सकता।\nBack up the data deliberately, not the machines accidentally. सिस्टम कोड से परिभाषित होने के बाद बैकअप केंद्रित और ईमानदार हो जाते हैं: डेटाबेस डंप, ऑब्जेक्ट स्टोरेज replication, कॉन्फ़िगरेशन रिपॉजिटरी, secrets vaults. सब कुछ की रात-रात इमेज के बजाय वास्तव में महत्वपूर्ण चीज़ों के छोटे, verifiable सेट।\nConsider keeping data off the processing systems entirely. एप्लिकेशन लगभग कुछ भी लोकल नहीं रख सकते: state managed डेटाबेस में, फाइलें ऑब्जेक्ट स्टोरेज में, secrets vault में। तब प्रोसेसिंग टियर में चुराने लायक कुछ नहीं बचता, जिसका मतलब है कि कंप्रोमाइज्ड एप्लिकेशन सर्वर reportable घटना के बजाय operational परेशानी भर है। बोनस के रूप में, स्टोरेज के लिए बनी डेटा सर्विसेज में बिल्ट-इन सुरक्षा, versioning, immutability options, fine-grained access control, किसी सामान्य सर्वर से कहीं बेहतर होती है।\nएक फ्लीट चलाएं, तीन नहीं #इसी सरलीकरण के अंदर एक और छिपा है, और वह फ्लीट से जुड़ा है। Windows और Linux के मिश्रित estate चलाने वाले किसी भी संगठन की लागत संरचना देखें और duplication गिनें:\nदो skill sets. Windows administration और Linux administration अलग पेशे हैं। दोनों का समर्थन करने का मतलब है या तो हर एक के specialist hire करना या दोनों की उथली कवरेज स्वीकार करना। लगभग बोलचाल में, उतनी ही मशीनों के लिए दोगुनी टीम। दो toolchains. Patching, monitoring, configuration management, hardening baselines, agent deployments: हर चीज़ duplicate में मौजूद, हर एक licensed, maintained और upgraded अलग से। दोगुना बजट, management infrastructure में दोगुनी attack surface, और दोगुनी चीज़ें जो चुपचाप पीछे छूट सकती हैं। दो failure modes. Incident response playbooks, forensic क्षमता और disaster recovery प्रक्रियाएं प्रत्येक platform के लिए fork हो जाती हैं। किसी incident के दौरान यह fork ठीक वही समय खा जाता है जो आपके पास नहीं होता। एयरलाइन वाली उपमा यहां पूरी तरह सटीक बैठती है। कोई सफल carrier हर aircraft type नहीं उड़ाता: हर अतिरिक्त type maintenance programs, spare parts inventory, crew certifications, training pipelines और hangar tooling को गुणा कर देता है, और वे लागत हमेशा दोहराई जाती हैं, खरीद के फैसले यादों से उड़ने के बहुत बाद तक। एयरलाइंस इसलिए अपने routes की सेवा करने वाले सबसे छोटे types सेट पर बेरहमी से standardise करती हैं। IT estates के साथ भी यही हिसाब होना चाहिए। अपना standard OS चुनना और उस पर कायम रहना दो को एक में बदल देता है, और बचत हर साल compound होती है।\nStandardisation सीधे सुरक्षा को भी मजबूत करती है। एक फ्लीट का मतलब है एक hardening baseline जिसे गहराई से समझा गया; एक patching pipeline जिसे tune और trust किया गया; detection rules का एक ही सेट जो असली estate के अनुरूप हो। Depth हर बार coverage को हराती है।\nकहां से शुरू करें # एक workload चुनें और उसे disposable बनाएं। उसे कोड से इतनी बार rebuild करें कि पूरा रिप्लेसमेंट मिनटों में हो और उसमें कुछ भी hand-configured न बचे। अपना डेटा ईमानदारी से inventory करें। वह कहां रहता है, किन सिस्टम्स पर, किसके नियंत्रण में, और कल क्या डिलीट किया जा सकता है। State को application servers से बाहर ले जाएं proper access control और immutability options वाले purpose-built storage में। फ्लीट split की लागत ईमानदारी से निकालें। Duplicated licences, tools और headcount को consolidation की कीमत के आमने रखें। Leadership के सामने वैसे ही पेश करें जैसे एयरलाइन route का मूल्यांकन करती है: recurring cost बनाम recurring revenue। आगे का standard सेट करें: नए सिस्टम standard fleet में शामिल होंगे, कोड से परिभाषित, जहां तक हो सके stateless. Exceptions के लिए लिखा हुआ कारण चाहिए। Separation of concerns इंजीनियरिंग का सबसे पुराना सबक है, और सुरक्षा को उसे शाब्दिक रूप से लागू करने से फायदा होता है: सिस्टम ephemeral हैं, डेटा permanent है, और हर एक की असली प्रकृति के अनुसार उनकी रक्षा करना दोनों को बुरी तरह बचाने से सस्ता पड़ता है।\nक्या आपका critical डेटा हर उस सर्वर के नुकसान से बच जाएगा जिसे वह छूता है? सीधी समझ-जांच के लिए संपर्क करें: LINE (@PureSecurity) या email (hello@puresecurity.com). हमारा Configuration \u0026amp; Architecture Assessment मैप करता है कि आपका डेटा कहां रहता है बनाम कहां process होता है और separation path डिज़ाइन करता है, और हमारी Linux hardening practice वह single-fleet baseline बनाती है जो standardisation को फायदेमंद बनाती है। या Engineering \u0026amp; Scoping Session schedule करें और इसे अपनी टीम के साथ plan करें।\n","date":"18 सितंबर 2024","permalink":"https://puresecurity.com/hi/posts/separating-data-from-systems/","section":"सुरक्षा विश्लेषण एवं तकनीकी सलाह","summary":"","title":"अपने डेटा को अपने सिस्टम से अलग करें: डिज़ाइन द्वारा अपरिवर्तनीय"},{"content":"जो विशेषज्ञ आपके कार्य का दायरा तय करता है, वही उसे व्यक्तिगत रूप से पूरा करता है।\nविशेषज्ञ तकनीकी निष्पादन #Pure Security को इस तरह तैयार किया गया है कि कार्य का दायरा तय करने वाला विशेषज्ञ ही सीधे आपके प्रोजेक्ट पर काम करता है। आपको सीआईएसओ स्तर की विशेषज्ञता और व्यावहारिक सुरक्षा इंजीनियरिंग तक सीधी पहुंच मिलती है।\nयह काम 20+ वर्षों के सुरक्षा नेतृत्व पर टिका है: 12 jurisdictions में 100+ वित्तीय संस्थाओं की सेवा करने वाले APAC payment processor के पूर्व CISO, एक Thai banking group के data और AI ventures के information security प्रमुख, एक global technology platform के enterprise GRC lead, और Australia के air traffic critical infrastructure के लिए 24x7 security operations प्रमुख।\nपूर्व करियर की नींव Australian Signals Directorate में रखी गई, जहां Information Security Manual सहित राष्ट्रीय defensive policy का लेखन और nation-state खतरों के खिलाफ defensive operations का नेतृत्व किया गया, इसके बाद high-assurance government और enterprise platforms के लिए site reliability engineering।\nहमारी कार्य सीमा # थाईलैंड: हमारा गृह बाजार, बैंक ऑफ थाईलैंड (BOT) और थाई एसईसी की अपेक्षाओं के तहत विनियमित क्षेत्रों का समर्थन। व्यापक एपीएसी: बहु-देशीय व्यापारिक समूहों के लिए सीमा-पार सुरक्षा कार्यक्रम। हमने क्षेत्र के 10 से अधिक नियामक ढांचों के अनुरूप सुरक्षा कार्यक्रम बनाए हैं: नियामक अनुपालन, तकनीकी सुरक्षा इंजीनियरिंग, और रणनीतिक शासन। पूर्व-स्वीकृत बिजनेस वीजा: हम आपकी टीम के साथ तुरंत काम करने के लिए तैयार हैं। हमारे पास अधिकांश एपीएसी देशों के बिजनेस वीजा उपलब्ध हैं, जिनमें ऑस्ट्रेलिया, ब्रुनेई, चीन, हांगकांग, इंडोनेशिया, जापान, कोरिया, मलेशिया, न्यूजीलैंड, फिलीपींस, सिंगापुर, ताइवान, थाईलैंड और वियतनाम शामिल हैं: China Australia Indonesia Japan New Zealand Philippines Papua New Guinea Malaysia Thailand Vietnam South Korea Taiwan Hong Kong SAR Brunei Singapore स्पष्ट और व्यावहारिक परिणाम #हमारे द्वारा उठाए गए हर निष्कर्ष के साथ एक जिम्मेदार व्यक्ति, समाधान की दिशा और लागत का अनुमान शामिल होता है। रिपोर्ट में स्पष्ट बताया जाता है कि क्या परीक्षण हुआ और क्या नहीं।\nपारदर्शी और उचित मूल्य निर्धारण #प्रस्ताव प्रस्तुत करने से पहले दरें साझा की जाती हैं और दायरा लिखित रूप में तय किया जाता है। यदि कोई कार्य हमारे अनुकूल नहीं है, तो हम स्पष्ट रूप से मना कर देते हैं और अन्य विश्वसनीय भागीदार की सिफारिश करते हैं।\nबातचीत शुरू करें #अपनी आवश्यकता बताएं और आप सीधे उसी विशेषज्ञ से बात करेंगे जो कार्य का निष्पादन करेगा।\nतकनीकी सलाह की आवश्यकता है? PCI-DSS के दायरे, बैंक ऑफ थाईलैंड के दिशानिर्देशों या अपनी सुरक्षा संरचना पर तकनीकी परामर्श के लिए संपर्क करें।\nLINE पर जुड़ें इंजीनियर को ईमेल करें ","date":null,"permalink":"https://puresecurity.com/hi/about/","section":"सीआईएसओ नेतृत्व वाली सुरक्षा एवं शासन","summary":"","title":"Pure Security के बारे में"},{"content":"सीधे अनुभवी सीआईएसओ या सक्रिय क्यूएसए से बात करें, किसी सेल्समैन से नहीं।\nबातचीत शुरू करें #अपनी जरूरत बताएं और आप सीधे उसी विशेषज्ञ से बात करेंगे जो समाधान वितरित करेगा। प्रत्येक चर्चा पूरी तरह गोपनीय और बिना किसी दायित्व के होती है।\nसंपर्क माध्यम #hello@puresecurity.com\nLINE: @PureSecurity\n+66 88 788 8600\nप्रारंभिक जानकारी में क्या शामिल करें #शुरुआत में यह जानकारी साझा करने से समय की बचत होती है:\nअपेक्षित परिणाम और समय सीमा संबंधित सेवा स्तंभ: अनुपालन, तकनीकी सुरक्षा या शासन लागू होने वाले मानक (PCI DSS 4.0.1, ISO 27001, NIST CSF, BOT दिशानिर्देश) प्रतिक्रिया समय #हम एक कार्यदिवस (बैंकॉक समय, UTC+7) के भीतर जवाब देते हैं। DFIR रिटेनर अनुबंध वाले ग्राहकों को लिखित गारंटीकृत प्रतिक्रिया समय मिलता है।\nDFIR रिटेनर अनुबंध ग्राहक? #रिटेनर ग्राहक सीधे प्राथमिकता प्राप्त करते हैं: गारंटीकृत प्रतिक्रिया समय, समर्पित इंजीनियर, और पहले कॉल से साक्ष्य सुरक्षा मार्गदर्शन। विवरण के लिए DFIR रिटेनर एवं आंतरिक जांच देखें।\nसक्रिय सुरक्षा घटना? #क्या आप किसी सक्रिय सुरक्षा घटना का सामना कर रहे हैं? विषय में इसका उल्लेख करें और हम इसे तुरंत प्राथमिकता देंगे।\n","date":null,"permalink":"https://puresecurity.com/hi/contact/","section":"सीआईएसओ नेतृत्व वाली सुरक्षा एवं शासन","summary":"","title":"Pure Security से संपर्क करें"},{"content":"हम कौन हैं #Pure Security Company Limited (\u0026ldquo;Pure Security\u0026rdquo;, \u0026ldquo;हम\u0026rdquo;) थाईलैंड और व्यापक APAC क्षेत्र के संगठनों को managed security, governance और assurance सेवाएं प्रदान करता है।\nहम क्या एकत्र करते हैं # पूछताछ डेटा: आपके संपर्क करने पर नाम, संगठन, ईमेल पता और आपके संदेश की सामग्री। एंगेजमेंट डेटा: सेवा देने के लिए आवश्यक क्लाइंट कर्मियों का संपर्क विवरण। तकनीकी डेटा: मानक सर्वर रिक्वेस्ट डेटा। यह साइट कोई analytics, advertising या third-party tracking का उपयोग नहीं करती, और fonts third-party CDN से लोड होने के बजाय self-hosted हैं। हम इन्हें कैसे उपयोग करते हैं #हम पूछताछ डेटा का उपयोग आपके अनुरोध का जवाब देने के लिए करते हैं, और एंगेजमेंट डेटा का उपयोग आपके संगठन के साथ तय सेवाएं देने के लिए करते हैं।\nकितने समय तक रखते हैं #पूछताछ डेटा अंतिम संपर्क से 24 महीने तक रखा जाता है। एंगेजमेंट रिकॉर्ड contract और लागू कानूनी दायित्वों की अवधि तक रखे जाते हैं, फिर सुरक्षित रूप से नष्ट कर दिए जाते हैं।\nसाझा करना #हम व्यक्तिगत डेटा बेचते नहीं हैं। हम इसे तीसरे पक्ष के साथ साझा नहीं करते, सिवाय जहां कानून अनिवार्य हो, या जहां सेवा देने के लिए sub-processor आवश्यक हो और समकक्ष दायित्वों से बंधा हो।\nआपके अधिकार #आप access, rectification, erasure, processing प्रतिबंध, portability का अनुरोध कर सकते हैं या अपने व्यक्तिगत डेटा की processing पर आपत्ति कर सकते हैं। इनका उपयोग करने के लिए hello@puresecurity.com पर संपर्क करें।\nबदलाव #इस नीति में महत्वपूर्ण बदलाव अपडेट किए गए revision date के साथ यहां दर्शाए जाएंगे।\n","date":null,"permalink":"https://puresecurity.com/hi/privacy/","section":"सीआईएसओ नेतृत्व वाली सुरक्षा एवं शासन","summary":"","title":"गोपनीयता नीति"},{"content":"Pure Security तीन मुख्य स्तंभों में संगठित है: सक्रिय QSA द्वारा मान्य नियामक अनुपालन, व्यावहारिक कॉन्फ़िगरेशन के रूप में वितरित तकनीकी सुरक्षा इंजीनियरिंग, और वास्तविक जवाबदेही वाला रणनीतिक शासन।\nयह मॉडल जानबूझकर प्रत्यक्ष और सीधा है। जो विशेषज्ञ आपके काम का दायरा तय करता है, वही उसे वितरित करता है, ताकि मूल्यांकन और सुधारात्मक कार्रवाई के बीच कुछ भी न छूटे, और प्रत्येक सिफारिश उस व्यक्ति से आती है जिसने स्वयं उन नियंत्रणों को संचालित किया है।\nबड़े उद्यमों के लिए, इसका मतलब एक ऐसा मूल्यांकनकर्ता है जो आपकी मेज के पक्ष में बैठ चुका है: एक पूर्व CISO जिसने बोर्ड, नियामकों और केंद्रीय बैंक के परीक्षकों को जवाब दिया है। बढ़ती कंपनियों के लिए, इसका मतलब आपके बजट के अनुकूल पैमाने पर वरिष्ठ क्षमता है, जिसका दायरा काम शुरू होने से पहले लिखित रूप में तय किया जाता है।\nजहाँ हम किसी नियंत्रण को डिज़ाइन या संचालित करते हैं, वहाँ हम उस नियंत्रण का स्वतंत्र आश्वासन अलग रखते हैं, ताकि आपको मिलने वाली सलाह पूरी तरह वस्तुनिष्ठ रहे।\n","date":null,"permalink":"https://puresecurity.com/hi/services/","section":"सुरक्षा सेवाएं","summary":"","title":"सुरक्षा सेवाएं"}]