PCI Compliance WiFi: एक मल्टी-साइट सुरक्षा मार्गदर्शिका

बहुतेक pci compliance wifi मार्गदर्शक "गेस्ट SSID तयार करा" वर थांबतात. वास्तविक ऑडिटमध्ये टिकून राहण्यासाठी तो सल्ला खूप अपुरा आहे. PCI व्याप्ती ही नेटवर्कवरील नावाने ठरवली जात नाही, तर ती ट्रॅफिक पाथ, कनेक्टिव्हिटी आणि कार्डधारक डेटा एन्व्हायर्नमेंट वेगळे राहते याच्या पुराव्यावरून ठरवली जाते.

जर वायरलेस सिस्टीम पेमेंट सिस्टीमपर्यंत पोहोचू शकत असेल, किंवा ती पोहोचू शकत नाही हे तुम्ही सिद्ध करू शकत नसाल, तर ते या संभाषणाचा भाग आहे. PCI मार्गदर्शनाने वर्षानुवर्षे WiFi कडे पेमेंट-सुरक्षा चिंता म्हणून पाहिले आहे, आणि मूळ नियम बदललेला नाही, स्कोप डेटा फ्लोनुसार ठरतो, लेबलनुसार नाही (PCI वायरलेस मार्गदर्शक तत्त्वे). याचा अर्थ असा की जर मूळ पाथ अजूनही CDE ला स्पर्श करत असेल तर गेस्ट SSID, कॉर्पोरेट SSID आणि "तात्पुरते" VLAN या सर्वांना काहीही अर्थ उरत नाही.

अनुक्रमणिका

• Guest WiFi हे स्वयंचलितपणे PCI व्याप्तीबाहेर का नसते
  • SSID वरील लेबल हे नियंत्रण नाही
  • व्याप्ती कशावरून ठरते
• असेसॉर स्वीकारेल अशा पुराव्यांसह वायरलेस सेगमेंटेशन सिद्ध करणे
  • पुराव्यांची साखळी तयार करा
  • बदलांपूर्वी आणि नंतर काय सत्यापित करावे
• PCI वायरलेससाठी योग्य प्रमाणीकरण मॉडेल निवडणे
• Identity-Driven VLANs, Cloud RADIUS आणि मजूबत क्रिप्टोग्राफी
  • ओळख योग्य ठिकाणी पोहोचणे आवश्यक आहे
  • मजबूत क्रिप्टोग्राफी हा व्याप्तीच्या कथेचा एक भाग आहे
• लॉगिंग, देखरेख आणि संशयास्पद ॲक्सेस पॉइंट शोधणे
  • कार्यक्षम ठरणारे देखरेख चक्र
  • डायग्रामिंग मानकांकडे दुर्लक्ष करू नका
• सर्वात सामान्य वायरलेस PCI निष्कर्षांसाठी निवारण प्लेबुक
  • त्रुटी दुरुस्त करा, नंतर दुरुस्ती सिद्ध करा
  • ऑडिट प्रभावाच्या आधारे बॅकलॉगला प्राधान्य द्या
• असेसर्स वायरलेसबद्दल काय विचारतात

गेस्ट WiFi आपोआप PCI च्या कक्षेबाहेर का जात नाही

स्वतंत्र गेस्ट SSID मूळतः WiFi ला सुरक्षित बनवत नाही, आणि स्वतंत्र VLAN देखील याचे निवारण करत नाही. PCI स्कोप केवळ तेव्हाच हटवला जातो जेव्हा वायरलेस कार्डधारक डेटा वातावरणापासून (CDE) वेगळे केले जाते आणि ते पृथक्करण केवळ लेबलमध्ये नाही तर पाथमध्ये लागू केले जाते. PCI DSS 4.0.1 ला सर्व वायरलेस नेटवर्क आणि CDE दरम्यान नेटवर्क सुरक्षा नियंत्रणे आवश्यक आहेत, ज्यामध्ये वायरलेस ट्रॅफिक बाय डीफॉल्ट नाकारले जाते आणि केवळ व्यावसायिकदृष्ट्या योग्य ट्रॅफिकला अनुमती दिली जाते (PCI वायरलेस मार्गदर्शक तत्त्वे).

SSID वरील लेबल हे नियंत्रण नाही

रूट अस्तित्वात असल्यास, तडजोड केलेला (compromised) ॲक्सेस पॉइंट, कंट्रोलर किंवा स्विच तरीही पेमेंट नेटवर्कमध्ये ब्रिज करू शकतो. "Guest WiFi" हे हेतूचे वर्णन आहे. हे असे नियंत्रण नाही जे असेसर पडताळू शकेल.

व्यवहारीक नियम: जर तुम्ही ट्रॅफिक कुठे थांबतो हे दाखवू शकत नसाल, तर तुम्ही सेगमेंटेशन दाखवले नाही.

कठीण भाग म्हणजे आयसोलेशन सिद्ध करणे. PCI मार्गदर्शक तत्त्वे देखील चेतावणी देतात की केवळ पेमेंट सिस्टम्स त्याच्याशी हेतूपुरस्सर जोडलेल्या नाहीत म्हणून वायरलेस हानीरहित आहे असे गृहीत धरू नका, आणि यासाठी अनधिकृत वायरलेस तंत्रज्ञान लागू केले गेले नाही याची नियतकालिक पडताळणी आवश्यक आहे.

व्याप्ती कशावरून ठरते

प्रश्न थेट आहे: त्या वायरलेस नेटवर्कमधील कोणताही ट्रॅफिक पाथ CDE पर्यंत पोहोचू शकतो का? जर पोहोचू शकत असेल, तर ते नेटवर्क स्कॉपमध्ये आहे. जर पोहोचू शकत नसेल, तर ब्लॉक वास्तविक आहे, लागू केला आहे आणि त्याचे मॉनिटरिंग केले जात आहे याचा पुरावा तुम्हाला अजूनही आवश्यक आहे.

मल्टी-साइट वातावरणात जेथे ॲक्सेस पॉइंट्स, स्विचेस, फायरवॉल, कॅमेरे, टिल्स आणि कर्मचाऱ्यांची डिव्हाइसेस एकाच फॅब्रिकचा वापर करतात, तेथे पुरावा अधिक महत्त्वाचा ठरतो. जर राउटिंग, कंट्रोलर पॉलिसी किंवा शेअर केलेले स्विच अपलिंक एखादा लपलेला मार्ग उघडा ठेवत असेल, तर केवळ एक नीटनेटके SSID नाव मदत करणार नाही. यासाठी एक उपयुक्त तुलना म्हणजे Purple Access चे तीन-SSID ॲप्रोच आहे, जे ओळख आणि नेटवर्क भूमिकेला SSID लेबलपेक्षा वेगळे मानते.

असेसर स्वीकारेल अशा पुराव्यांसह वायरलेस सेगमेंटेशन सिद्ध करणे

सेगमेंटेशन फक्त तेव्हाच मोजले जाते जेव्हा तुम्ही ते वायरवर सिद्ध करू शकता. डॅशबोर्डपासून नाही, तर फायरवॉलपासून सुरुवात करा. PCI मार्गदर्शनानुसार सेगमेंटेशन नियंत्रणांनी वायरलेस नेटवर्क आणि CDE मधील ट्रॅफिक ब्लॉक करणे अपेक्षित आहे आणि किमान वार्षिक आधारावर सेगमेंटेशनची पेनिट्रेशन-चाचणी करणे आवश्यक आहे, तसेच नेटवर्क, फायरवॉल, कंट्रोलर, VLAN, ओळख किंवा पेमेंट-ॲप्लिकेशनमध्ये महत्त्वपूर्ण बदल झाल्यानंतरही ते आवश्यक आहे.

पुराव्याची साखळी तयार करा

प्रत्येक वेळी तोच पुराव्याचा नमुना वापरा, जेणेकरून ॲक्सेसरला एक-वेळच्या स्क्रीनशॉटऐवजी पुनरावृत्ती करता येण्याजोगे नियंत्रण दिसेल. चाचणीसाठी वापरलेला AP इन्व्हेंटरी स्नॅपशॉट अटॅच करा, त्यानंतर चाचणीच्या क्षणी फायरवॉल, स्विच आणि कंट्रोलरची स्थिती दाखवा. नियमितपणे कंट्रोलर डेटा, स्विच डेटा, DHCP रेकॉर्ड आणि वायरलेस इंट्रुजन डिटेक्टशन निकालांशी त्याची तुलना करा. स्विच-साइड व्हॅलिडेशनसाठी, IT Cloud Global चे नेटवर्क स्विच मार्गदर्शन हा एक उपयुक्त संदर्भ आहे.

कागदावरील फायरवॉल नियम पुरेसा नाही. तैनात केलेला पाथ ट्रॅफिक ब्लॉक करतो याचा पुरावा तुम्हाला हवा आहे.

नकारात्मक चाचण्या महत्त्वाच्या असतात. संशयास्पद AP ब्रिजिंग, अनधिकृत क्लायंट असोसिएशन, VLAN हॉपिंग, कमकुवत प्रशासकीय ॲक्सेस आणि पेमेंट टर्मिनल्सवरील अपघाती ॲक्सेसची चाचणी करा. जर एखादी चाचणी फक्त नियम अस्तित्वात असल्याची पुष्टी करत असेल, तर ती सेग्मेंटेशन चाचणी नाही. तो केवळ कॉन्फिगरेशनचा स्क्रीनशॉट आहे.

बदलांपूर्वी आणि नंतर काय सत्यापित करावे

नेटवर्कमधील बदलामुळे एका रात्रीत तुमचे पुरावे अमान्य होऊ शकतात. कंट्रोलर अपडेट्स, फायरवॉलमधील बदल, VLAN रीडिझाइन, ओळख (identity) बदल किंवा पेमेंट-अॅपमधील बदल यांच्यानंतर चाचण्या पुन्हा चालवा. त्रुटी शोधण्यासाठी वार्षिक ऑडिटच्या हंगामाची वाट पाहू नका.

तुम्हाला स्विच आणि कंट्रोलरच्या स्वच्छतेबद्दल विचार करण्याचा व्यावहारिक मार्ग हवा असल्यास, तीन-SSID वायरलेस सेगमेंटेशन डिझाइन मधील मार्गदर्शन हे एक उपयुक्त माध्यम आहे, कारण तोच ऑपरेशन्समधील शिस्त सेगमेंटेशनच्या पुराव्यालाही लागू होते. मुद्दा असा आहे की राउटिंग, स्विचिंग आणि फायरवॉल पॉलिसी अपेक्षित आयसोलेशनशी सुसंगत आहेत हे दाखवणे.

जेव्हा तुम्ही हे असेसरासाठी तयार करता, तेव्हा सर्व आर्टिफॅक्ट्स, टेस्ट प्लॅन, टेस्ट निकाल, रेमेडिएशन नोट्स आणि रीटेस्टचे पुरावे एकत्र ठेवा. हा संच "आम्हाला वाटते की ते आयसोलेटेड आहे" चे रुपांतर "आम्ही ते सिद्ध केले आहे" मध्ये करतो.

PCI वायरलेससाठी योग्य प्रमाणीकरण मॉडेल निवडणे

शेअर केलेले पासवर्ड हे सर्वात कमकुवत स्वीकार्य उत्तर आहे आणि प्रत्यक्ष ऑपरेशन्समध्ये ते क्रॅक करणे सर्वात सोपे असते. कर्मचारी बदलतात. कंत्राटदार सोडून जातात. कन्सेशन्स बदलतात. खूप जास्त काळ वापरलेला PSK हा दायित्व बनतो, जरी वायरलेस सिग्नल स्वतः सेगमेंट केला गेला असला तरीही. PCI वातावरणासाठी, ऑथेंटिकेशनने अनन्य ॲक्सेस, टार्गेटेड रिव्होकेशन आणि स्पष्ट ओळख मॅपिंगला सपोर्ट केला पाहिजे.

येथे थेट तुलना दिली आहे.

मॉडेल	शेअर केलेला गुप्त शब्द धोका	प्रति-डिव्हाइस रद्द करणे	VLAN मॅपिंगसाठी ओळख	PCI 4.0.1 सुसंगतता
शेअर केलेला PSK	उच्च, एक गुप्त शब्द अनेक वापरकर्ते किंवा उपकरणांमध्ये शेअर केला जातो	कमकुवत, एका वापरकर्त्याचा बदल करणे म्हणजे सहसा संपूर्ण की बदलणे	मर्यादित, ओळख अस्पष्ट होते	कर्मचारी आणि ऑपरेशनल नेटवर्कसाठी अयोग्य
EAP-TLS सह WPA2-Enterprise	कमी, क्रेडेन्शियल्स उपकरणांवरील प्रमाणपत्रांशी जोडलेली असतात	मजबूत, WLAN ची पुनर्रचना न करता एक प्रमाणपत्र रद्द केले जाऊ शकते	मजबूत, RADIUS वापरकर्ते आणि उपकरणांचे धोरणांशी मॅपिंग करू शकते	कर्मचारी प्रवेशासाठी अत्यंत सुसंगत
प्रति-डिव्हाइस xPSK	शेअर केलेल्या PSK पेक्षा कमी, प्रत्येक उपकरणाला किंवा भाडेकरूला स्वतःची की मिळते	मजबूत, इतरांना प्रभावित न करता एक की काढली जाऊ शकते	चांगले, ओळख धोरण आणि रद्द करण्याची प्रक्रिया नियंत्रित करू शकते	BYOD, IoT, सवलतींसाठी अत्यंत सुसंगत

कर्मचाऱ्यांसाठी EAP-TLS सह WPA2-Enterprise हे सर्वात स्पष्ट मॉडेल आहे. हे तुम्हाला सर्टिफिकेट-आधारित विश्वास देते आणि ऑडिओटर्सना नावडणारा सामायिक-गुपित मेस (shared-secret mess) काढून टाकते. BYOD, IoT किंवा सवलतीच्या उपकरणांसाठी (concession devices), प्रति-डिव्हाइस किंवा प्रति-भाडेकरू xPSKs हे ऑपरेशनल दृष्टिकोनातून अधिक योग्य आहेत, कारण तुम्ही संपूर्ण नेटवर्क बंद न करता एका डिव्हाइसचा ॲक्सेस रद्द करू शकता.

कार्यक्षम नियम: जर तुम्ही इतर कोणाचाही ॲक्सेस न बदलता एका डिव्हाइसचा ॲक्सेस रद्द करू शकत नसाल, तर हे मॉडेल खूपच अयोग्य आहे.

ओळख-आधारित डिझाइनसाठी, Purple Access चे ओळख-आधारित नेटवर्किंग पेज पुनरावलोकन करण्यासारखे आहे कारण ते एकाच शेअर केलेल्या क्रेडेंशियलऐवजी वापरकर्ता आणि डिव्हाइस ओळखीच्या आभोवती वायरलेस ॲक्सेस फ्रेम करते. मल्टी-साइट इस्टेटमधील pci compliance wifi साठी ते योग्य मेंटल मॉडेल आहे.

Guest WiFi हे CDE कडे जाणारा कोणताही मार्ग नसलेल्या समर्पित पाथवर असले पाहिजे. कर्मचाऱ्यांच्या ॲक्सेससाठी सर्टिफिकेट्स वापरली पाहिजेत. इतर सर्व गोष्टी स्पष्ट, रद्द करता येण्याजोग्या आणि ऑडिट करता येण्याजोग्या असाव्यात.

ओळख-आधारित VLANs, क्लाउड RADIUS, आणि मजबूत क्रिप्टोग्राफी

ऑथेन्टिकेशन तेव्हाच उपयुक्त ठरते जेव्हा RADIUS योग्य सेगमेंटशी आयडेंटिटी मॅप करतो. PCI वायरलेस डिझाइनमध्ये, कंट्रोल पाथ आयडेंटिटी स्टोअरपासून RADIUS ते VLAN आणि पुढे फायरवॉल पॉलिसीपर्यंत चालतो, आणि प्रत्येक हँडऑफ पडताळण्यायोग्य असावा लागतो.

ओळख योग्य ठिकाणी पोहोचली पाहिजे

Microsoft Entra ID, Okta किंवा Google Workspace सारख्या सिस्टीमद्वारे डिरेक्टरी-बॅक्ड प्रोव्हिजनिंग नवीन जॉइनर्स, मूव्हर्स आणि लीव्हर्सना धोरणाशी सुसंगत ठेवते. जर ओळख बदलली परंतु VLAN असाइनमेंट बदलले नाही, तर नेटवर्क अद्याप जुन्या वापरकर्त्याला काहीही बदलले नाही असेच वागवते.

अंतर्निहित स्विचिंग लेयरसाठी, लहान व्यवसायासाठी VLAN सेटअप पहा, ज्यामध्ये ट्रंक आणि ॲक्सेस-पोर्ट कॉन्फिगरेशन समाविष्ट आहे जे हे RADIUS-असाइन केलेले सेग्मेंट्स वाहून नेते.

जेव्हा तुम्हाला विविध क्षेत्रांमध्ये किंवा साइट्सवर सातत्यपूर्ण ऑथेंटिकेशनची आवश्यकता असते तेव्हा Cloud RADIUS हे मॉडेल पूर्णपणे साध्य करते. Purple Access चे Cloud RADIUS हे ऑडिट लॉगिंग आणि रिव्होकेशन सपोर्टसह, ओळख-आधारित राउटिंगला योग्य SSID आणि VLAN शी जोडते. यामुळे वायरलेस ॲक्सेस हा स्टॅटिक MAC याद्यांऐवजी वर्तमान ओळखीशी जोडलेला राहतो.

मजबूत क्रिप्टोग्राफी हा कक्षेच्या नियमाचा एक भाग आहे

PCI वायरलेस मार्गदर्शन कार्डधारक डेटा वितरणासाठी वायरलेस नेटवर्कला सार्वजनिक नेटवर्क मानते, त्यामुळे PAN ट्रॅफिकला TLS, IPsec, किंवा WPA2-AES सारख्या मजबूत क्रिप्टोग्राफीची आवश्यकता असते (PCI वायरलेस मार्गदर्शक तत्त्वे). "सुरक्षित WiFi" आणि अनुपालन असणारे WiFi या एकच गोष्टी नाहीत. क्रिप्टो पर्याय लिंकवरून जाणाऱ्या डेटाशी सुसंगत असणे आवश्यक आहे.

MDM द्वारे सर्टिफिकेट-आधारित ऑनबोर्डिंग खाजगी की (private keys) सामायिक पासवर्डपासून दूर ठेवते आणि कर्मचाऱ्यांच्या उपकरणांना अधिक स्पष्ट ट्रस्ट मॉडेल देते. मिश्रित वातावरणासाठी, कर्मचाऱ्यांसाठी सर्टिफिकेट्स, पूर्ण एंटरप्राइज ऑथेंटिकेशन चालवू न शकणाऱ्या उपकरणांसाठी xPSKs आणि पेमेंट सिस्टमपर्यंत कधीही न पोहोचणाऱ्या मार्गावर गेस्ट ॲक्सेस वापरा.

लॉगिंग, देखरेख, आणि अनधिकृत ॲक्सेस पॉइंट शोधणे

लिखित स्वरूपातील नो-WiFi पॉलिसीमुळे रोग-डिटेक्शनची (rogue-detection) जबाबदारी संपत नाही. PCI संस्थांकडून अधिकृत आणि अनधिकृत दोन्ही वायरलेस ॲक्सेस पॉइंट्सचे व्यवस्थापन करण्याची अपेक्षा करते, त्यामुळे हे नियंत्रण केवळ दस्तऐवजीकृत न राहता सक्रिय असले पाहिजे.

कार्यक्षम असणारे देखरेख चक्र

मंजूर AP इन्व्हेंटरीसह सुरुवात करा, त्यानंतर त्याकडे एक थेट नियंत्रण रेकॉर्ड म्हणून पाहा. यामध्ये मालक, स्थान, हार्डवेअर पत्ता, SSIDs, कंट्रोलर, फर्मवेअर आणि AP हे CDE पर्यंत पोहोचू शकते की नाही याचा समावेश करा. एका ठराविक आठवड्याच्या टप्प्यावर इन्व्हेंटरीची तुलना करा आणि डिफरन्स आउटपुट जतन करा, कारण मूल्यांकनकर्ता (assessor) विचारेल की शेवटची तुलना कधी झाली होती आणि त्यात काय आढळले.

त्या इन्व्हेंटरीची तुलना कंट्रोलर डेटा, स्विच डेटा, DHCP डेटा आणि वायरलेस घुसखोरी शोध आउटपुटशी करा. नंतर ड्रिफ्ट शोधा: नवीन BSSID, हलवलेले डिव्हाइस, फर्मवेअरची न जुळणारी स्थिती किंवा एका स्त्रोतावर दिसणारा परंतु इतरांवर न दिसणारा AP.

तुम्हाला अज्ञात BSSID दिसल्यास, त्याची तपासणी करा. डिव्हाइसचे भौतिकरित्या सत्यापन करा, त्याचे वर्गीकरण करा आणि ते अनधिकृत असल्यास ते क्वारंटाइन करा किंवा काढून टाका. अलर्ट, तपासणीच्या नोंदी आणि उपायांचे (remediation) पुरावे ठेवा. मूल्यांकनकर्त्याला कोणीतरी ते हाताळले असे सांगणाऱ्या वाक्यापेक्षा स्पष्ट पुरावा हवा असतो.

एक व्यावहारिक वायरलेस देखरेख चक्र याप्रमाणे असावे:

• प्रथम इन्व्हेंटरी करा: मालकी आणि प्लेसमेंटसह मंजूर केलेली यादी अद्ययावत ठेवा.
• वेळापत्रकानुसार क्रॉस चेक करा: दर आठवड्याला कंट्रोलर, स्विच, DHCP आणि WIDS डेटाची तुलना करा.
• अज्ञात बाबींची चौकशी करा: इन्व्हेंटरीशी जुळत नसलेल्या कोणत्याही BSSID किंवा AP ची चौकशी करा.
• प्रत्यक्षात पडताळणी करा: वर्गीकरण करण्यापूर्वी डिव्हाइसची प्रत्यक्ष खात्री करा.
• निवारण करा आणि सेव्ह ठेवा: डिव्हाइस क्वारंटाइन करा किंवा काढून टाका, त्यानंतर अलर्ट ट्रेल आणि तुलनेचे आउटपुट राखून ठेवा.

डायग्रामिंग मानकांकडे दुर्लक्ष करू नका

वायरलेस आकृत्यांनी सुरक्षा-नियंत्रण प्लेसमेंट आणि आउट-ऑफ-स्कोप WLANs सह सर्व संबंधित कनेक्शन दाखवले पाहिजेत. एका असेसराला वायरलेस फॅब्रिकचा CDE शी कसा संबंध आहे हे पाहणे आवश्यक असते, केवळ SSIDs कुठे ब्रॉडकास्ट होतात एवढेच नाही.

तुमचे मॉनिटरिंग फक्त तुम्ही काय तैनात करू इच्छित होता याचा अहवाल देत असेल, तर ते प्रत्यक्ष जागेवर काय दिसले हे चुकवेल.

सर्वात सामान्य वायरलेस PCI निष्कर्षांसाठी निवारण मार्गदर्शक

बहुतेक वायरलेस निष्कर्ष वारंवार येतात कारण टीम्स कंत्रोल अयशस्वी होण्याऐवजी लक्षणांवर उपाय करतात. त्या आकृती पुनर्संचयित करतात, पासवर्ड बदलतात किंवा कंट्रोलर पॅच करतात, परंतु पुराव्याची साखळी पुन्हा तयार होण्यापूर्वीच थांबतात. म्हणूनच मल्टी-साइट ऑडिटमध्ये तेच तेच मुद्दे पुन्हा समोर येत राहतात.

त्रुटी सुधारा, आणि नंतर ती दुरुस्ती सिद्ध करा

नेटवर्क बदलानंतर सेगमेंटेशन अयशस्वी झाल्यास, आयसोलेशन चाचण्या पुन्हा चालवा आणि निकाल सेव्ह करा. कर्मचाऱ्यांनी अद्याप पासवर्ड शेअर केल्यास, त्यांना सर्टिफिकेट्स किंवा प्रति-डिव्हाइस की वर हलवा. कंट्रोलर किंवा स्विच कॉन्फिगरेशन बदलले असल्यास, त्यांना पुन्हा पॉलिसीनुसार दुरुस्त करा आणि नवीन स्नॅपशॉट तारखेच्या ट्रेलसह स्टोअर करा.

कंट्रोलर किंवा स्विचवरील कमकुवत प्रशासकीय पाथला समान उपचारांची आवश्यकता असते. तो बंद करा, आणि नंतर तो बंद झाला आहे हे आक्रमक वापरेल त्याच दृष्टिकोनातून सिद्ध करा. जर थेट पाथ अजूनही लीक होत असेल तर इच्छित ACL अस्तित्वात आहे याने असेसराला काही फरक पडणार नाही.

ऑडिट प्रभावानुसार बॅकलॉगला प्राधान्य द्या

1. कोणत्याही नेटवर्क बदलानंतर सेगमेंटेशन सिद्ध करा. हा सर्वात जास्त मूल्याचा उपाय आहे कारण तो PCI च्या मूळ प्रश्नाला संबोधित करतो, वायरलेस CDE पर्यंत पोहोचू शकते का?
2. सामायिक केलेले पासवर्ड बदला. सामायिक केलेला ॲक्सेस सुरक्षितपणे रद्द करणे कठीण असते आणि मोठ्या प्रमाणावर तो चुकीच्या पद्धतीने हाताळला जाण्याची शक्यता असते.
3. फर्मवेअर आणि कॉन्फिगरेशन अपडेट करा. ड्रिफ्टमुळे कालचे अनुपालन केलेले डिझाइन आजचे असुरक्षित ठिकाण बनते.
4. रॉग AP रिस्पॉन्स दस्तऐवजीकृत करा. जर रिस्पॉन्स रेकॉर्ड केला गेला नाही, तर ते नियंत्रण काल्पनिक वाटते.
5. पुन्हा ऑडिट करा आणि निष्कर्ष बंद करा. प्रत्येक दुरुस्तीसाठी पुन्हा चाचणी केल्याचा पुरावा आवश्यक असतो, अन्यथा ते बंद मानले जात नाही.

सर्वोत्तम रेमेडिएशन पुरावा हा साधा असतो. तो बदल, चाचणी, निकाल आणि तारीख दाखवतो. ऑडिटर्स त्यावरच विश्वास ठेवतात.

मूल्यांकनकर्ते वायरलेसबद्दल काय विचारतात

Guest WiFi मुळे PCI स्कोप आपोआप कमी होत नाही. असेसर्स केवळ नेटवर्क आकृतीवरच नाही, तर प्रत्यक्ष व्यवहारात वायरलेस ट्रॅफिक CDE पर्यंत पोहोचू शकत नाही याचा पुरावा शोधतात.

त्यांना पुरावे हवे असतात, लेबल्स नाहीत. याचा अर्थ फायरवॉल नियम, राउटिंग पुनरावलोकने, कंट्रोलर आणि स्विच स्नॅपशॉट्स, पॅकेट चाचण्या आणि ट्रॅफिक डिझाइननुसार ब्लॉक केले आहे किंवा मर्यादित केले आहे हे दर्शवणारे लॉग्स. एक स्वतंत्र SSID केवळ तेव्हाच उपयुक्त ठरतो जेव्हा थेट पाथ त्याला सपोर्ट करतो.

ते रीटेस्ट ट्रेल देखील तपासतात. महत्त्वाच्या नेटवर्क, फायरवॉल, कंट्रोलर, VLAN, आयडेंटिटी किंवा पेमेंट-ॲप्लिकेशन बदलांनंतर वायरलेस सेग्मेंटेशन चाचणीची पुनरावृत्ती केली पाहिजे आणि असेसराला नवीनतम रीटेस्ट पुरावे पाहण्याची अपेक्षा असेल.

कंट्रोलर किंवा फायरवॉल मधील बदलानंतर, वायरलेस चाचण्या पुन्हा चालवा आणि आधीचे व नंतरचे निकाल एकत्र ठेवा. नियंत्रण बदलल्यास, पुरावाही त्यासोबत बदलला पाहिजे.

मल्टी-साइट सेटअप्सची अतिरिक्त तपासणी केली जाते. सामायिक इन्फ्रास्ट्रक्चरमुळे गेस्ट, कर्मचारी आणि पेमेंट ट्रॅफिकमधील फरक अस्पष्ट होऊ शकतो, त्यामुळे मूल्यांकनकर्ता सहसा सर्व साइट्सवर ओळख मॅपिंग, सेगमेंटेशन पुरावे आणि लाईव्ह मॉनिटरिंगची मागणी करतात. ते सामान्यतः शेवटच्या तीन रोग-AP तपासणीच्या रेकॉर्डची आणि सर्वात अलीकडील फायरवॉल बदल पुन्हा तपासला गेल्याच्या पुराव्याची मागणी करतात.

Purple Access ओळखीच्या आधारे वायरलेस ॲक्सेस मॉडेल करण्यास, RADIUS-संचालित पॉलिसीसह वापरकर्ते आणि डिव्हाइसेसचे वर्गीकरण करण्यास आणि ऑडिट पुरावे एकाच ठिकाणी ठेवण्यास मदत करते. तुम्ही अनेक साइट्सवर pci compliance wifi मजबूत करत असल्यास, Purple Access ला भेट द्या आणि त्याचे Cloud RADIUS, xPSK, आणि पुरावे देणारी टूल्स नियंत्रित वायरलेस डिझाइनमध्ये कशी बसतात याचे पुनरावलोकन करा.