PCI-DSS অনুবর্তী WiFi: একটি মাল্টি-সাইট সিকিউরিটি গাইড

বেশিরভাগ PCI কম্প্লায়েন্স WiFi গাইড "একটি গেস্ট SSID তৈরি করুন" এ গিয়ে থেমে যায়। এই পরামর্শটি একটি আসল অডিটে টিকে থাকার জন্য অত্যন্ত অগভীর। PCI এর পরিধি নেটওয়ার্কের নামের দ্বারা নির্ধারিত হয় না, এটি নির্ধারিত হয় ট্র্যাফিক পাথ, কানেক্টিভিটি, এবং প্রমাণের দ্বারা যা কার্ডহোল্ডার ডেটা এনভায়রনমেন্টকে পৃথক রাখে।

যদি কোনো ওয়্যারলেস সিস্টেম পেমেন্ট সিস্টেমে পৌঁছাতে পারে, অথবা এটি যে পারে না তা যদি আপনি প্রমাণ করতে না পারেন, তবে এটি এই আলোচনার অংশ। PCI নির্দেশিকা বহু বছর ধরে WiFi-কে পেমেন্ট সিকিউরিটির উদ্বেগ হিসেবে বিবেচনা করে আসছে, এবং মূল নিয়মটি পরিবর্তিত হয়নি - স্কোপ ডাটা প্রবাহকে অনুসরন করে, লেবেলকে নয় (PCI Wireless Guidelines)। এর অর্থ হলো একটি গেস্ট SSID, একটি কর্পোরেট SSID এবং একটি "অস্থায়ী" VLAN সবই অপ্রাসঙ্গিক যদি অন্তর্নিহিত পাথটি এখনও CDE-কে স্পর্শ করে।

সূচিপত্র

• কেন গেস্ট WiFi স্বয়ংক্রিয়ভাবে PCI Scope-এর বাইরে থাকে না
  • SSID-এর লেবেল আসল নিয়ন্ত্রণ ব্যবস্থা নয়
  • কোন বিষয়টি Scope নির্ধারণ করে
• মূল্যায়নকারীর গ্রহণযোগ্য প্রমাণ সহ ওয়্যারলেস Segmentation প্রমাণ করা
  • প্রমাণের চেইন তৈরি করুন
  • পরিবর্তনের আগে এবং পরে যা যাচাই করবেন
• PCI ওয়্যারলেসের জন্য সঠিক Authentication Model নির্বাচন করা
• Identity Driven VLANs, Cloud RADIUS, এবং শক্তিশালী Cryptography
  • Identity সঠিক স্থানে পৌঁছানো আবশ্যক
  • শক্তিশালী Cryptography হলো Scope বিবরণের অংশ
• Logging, Monitoring, এবং Rogue Access Point সনাক্তকরণ
  • কার্যকর Monitoring চক্র
  • Diagramming Standard ভুলে যাবেন না
• সবচেয়ে সাধারণ ওয়্যারলেস PCI Findings-এর জন্য Remediation Playbook
  • ত্রুটি সমাধান করুন, তারপর সমাধানের প্রমাণ দিন
  • Audit প্রভাব অনুযায়ী Backlog অগ্রাধিকার দিন
• ওয়্যারলেস সম্পর্কে মূল্যায়নকারীরা যা জিজ্ঞাসা করেন

কেন গেস্ট WiFi স্বয়ংক্রিয়ভাবে PCI স্কোপের বাইরে নয়

একটি পৃথক গেস্ট SSID ডিফল্টভাবে WiFi-কে নিরাপদ করে না এবং একটি পৃথক VLAN-ও এর সমাধান করে না। PCI স্কোপ কেবল তখনই সরিয়ে নেওয়া হয় যখন ওয়্যারলেসকে কার্ডহোল্ডার ডাটা এনভায়রনমেন্ট থেকে সেগমেন্ট করা হয় এবং সেই পৃথকীকরণ কেবল লেবেলে নয়, বরং পাথে কার্যকর করা হয়। PCI DSS 4.0.1 অনুযায়ী সমস্ত ওয়্যারলেস নেটওয়ার্ক এবং CDE-এর মাঝে নেটওয়ার্ক সুরক্ষা নিয়ন্ত্রণ থাকা আবশ্যক, যেখানে ওয়্যারলেস ট্রাফিক ডিফল্টভাবে নিষিদ্ধ থাকবে এবং কেবল ব্যবসার জন্য প্রয়োজনীয় ট্রাফিক অনুমোদিত হবে (PCI Wireless Guidelines)।

SSID-এর লেবেলটি কোনো নিয়ন্ত্রণ ব্যবস্থা নয়

রুট বিদ্যমান থাকলে একটি আপোসকৃত (compromised) অ্যাক্সেস পয়েন্ট, কন্ট্রোলার, বা সুইচ পেমেন্ট নেটওয়ার্কে ব্রিজ তৈরি করতে পারে। "গেস্ট WiFi" হলো উদ্দেশ্যের একটি বিবরণ। এটি এমন কোনো কন্ট্রোল নয় যা একজন অ্যাসেসর যাচাই করতে পারেন।

ব্যবহারিক নিয়ম: আপনি যদি দেখাতে না পারেন যে ট্র্যাফিক কোথায় থামছে, তবে আপনি সেগমেন্টেশন দেখাতে পারেননি।

কঠিন অংশ হলো আইসোলেশন প্রমাণ করা। PCI নির্দেশিকা সতর্ক করে যে কেবল পেমেন্ট সিস্টেমগুলো ওয়্যারলেসে সরাসরি যুক্ত নয় বলেই এটিকে নিরাপদ মনে করা যাবে না, এবং অননুমোদিত ওয়্যারলেস প্রযুক্তি প্রবর্তিত হয়নি তা নিশ্চিত করতে পর্যায়ক্রমিক যাচাইকরণের প্রয়োজন হয়।

কোন বিষয়টি Scope নির্ধারণ করে

প্রশ্নটি সরাসরি: সেই ওয়্যারলেস নেটওয়ার্ক থেকে কোনো ট্র্যাফিক পাথ কি CDE-তে পৌঁছাতে পারে? যদি পারে, নেটওয়ার্কটি বিবেচনাধীন রয়েছে। যদি না পারে, তবে ব্লকটি আসল, বলবৎ করা হয়েছে এবং পর্যবেক্ষণ করা হচ্ছে এমন প্রমাণের এখনও প্রয়োজন।

বহু-সাইট পরিবেশে সেই প্রমাণ অত্যন্ত গুরুত্বপূর্ণ যেখানে অ্যাক্সেস পয়েন্ট, সুইচ, ফায়ারওয়াল, ক্যামেরা, টিল এবং কর্মীদের ডিভাইস একই ফ্যাব্রিক শেয়ার করে। রাউটিং, কন্ট্রোলার পলিসি বা শেয়ার্ড সুইচ আপলিঙ্ক যদি কোনো লুকানো পথ খোলা রাখে, তবে একটি সুন্দর SSID নাম কোনো সাহায্য করবে না। একটি দরকারী তুলনা হলো Purple Access'র থ্রি-SSID পদ্ধতি, যা পরিচয় এবং নেটওয়ার্ক ভূমিকা বিবেচনা করে SSID লেবেল থেকে আলাদাভাবে কাজ করে।

অ্যাসেসর গ্রহণ করবেন এমন প্রমাণ সহ ওয়্যারলেস সেগমেন্টেশন প্রমাণ করা

সেগমেন্টেশন তখনই গণ্য হয় যখন আপনি এটি তারের ওপর প্রমাণ করতে পারেন। ড্যাশবোর্ড নয়, ফায়ারওয়াল দিয়ে শুরু করুন। PCI নির্দেশিকা ওয়্যারলেস নেটওয়ার্ক এবং CDE-এর মধ্যকার ট্রাফিক ব্লক করার জন্য সেগমেন্টেশন কন্ট্রোল প্রত্যাশা করে, এবং অন্তত বার্ষিকভাবে এবং উল্লেখযোগ্য নেটওয়ার্ক, ফায়ারওয়াল, কন্ট্রোলার, VLAN, পরিচয়, বা পেমেন্ট অ্যাপ্লিকেশনের পরিবর্তনের পরে সেগমেন্টেশন পেনাট্রেশন টেস্ট করার প্রয়োজন হয়।

প্রমাণের চেইন তৈরি করুন

প্রতিবার একই প্রমাণের প্যাটার্ন ব্যবহার করুন, যাতে অ্যাসেসর একটি পুনরাবৃত্তিযোগ্য নিয়ন্ত্রণ দেখতে পান, কোনো ওয়ান-অফ স্ক্রিনশট নয়। পরীক্ষার জন্য ব্যবহৃত AP ইনভেন্টরি স্ন্যাপশট সংযুক্ত করুন, তারপর পরীক্ষার মুহূর্তে ফায়ারওয়াল, সুইচ এবং কন্ট্রোলারের অবস্থা দেখান। নিয়মিতভাবে কন্ট্রোলার ডাটা, সুইচ ডাটা, DHCP রেকর্ড এবং ওয়্যারলেস ইনট্রুশন ডিটেকশন ফলাফলের সাথে তা তুলনা করুন। সুইচ-সাইড ভ্যালিডেশনের জন্য, IT Cloud Global's network switch advice একটি দরকারী রেফারেন্স।

কাগজে-কলমে থাকা একটি ফায়ারওয়াল নিয়ম যথেষ্ট নয়। মোতায়েন করা পাথটি যে ট্র্যাফিক ব্লক করে তার প্রমাণের প্রয়োজন।

নেগেটিভ টেস্ট অত্যন্ত গুরুত্বপূর্ণ। Rogue AP ব্রিজিং, অননুমোদিত ক্লায়েন্ট অ্যাসোসিয়েশন, VLAN হপিং, দুর্বল অ্যাডমিনিস্ট্রেটিভ অ্যাক্সেস এবং পেমেন্ট টার্মিনালে দুর্ঘটনাবশত অ্যাক্সেসের জন্য পরীক্ষা করুন। যদি কোনো পরীক্ষা কেবল নিয়মটি বিদ্যমান রয়েছে তা নিশ্চিত করে, তবে সেটি সেগমেন্টেশন টেস্ট নয়। এটি একটি কনফিগারেশন স্ক্রিনশট মাত্র।

পরিবর্তনের আগে এবং পরে কী যাচাই করতে হবে

একটি নেটওয়ার্ক পরিবর্তন রাতারাতি পরিষ্কার প্রমাণকে অকার্যকর করে দিতে পারে। কন্ট্রোলার আপডেট, ফায়ারওয়াল পরিবর্তন, VLAN পুনঃনকশা, পরিচয় পরিবর্তন, বা পেমেন্ট অ্যাপ পরিবর্তনের পরে পুনরায় পরীক্ষা পরিচালনা করুন। বিচ্যুতি খুঁজে পাওয়ার জন্য বার্ষিক অডিট সিজনের জন্য অপেক্ষা করবেন না।

আপনি যদি সুইচ এবং কন্ট্রোলার হাইজিন সম্পর্কে চিন্তা করার একটি ব্যবহারিক উপায় চান, তবে থ্রি-SSID ওয়্যারলেস সেগমেন্টেশন ডিজাইন-এর নির্দেশিকাটি একটি উপযোগী সহায়ক, কারণ সেগমেন্টেশন প্রমাণের ক্ষেত্রেও একই অপারেশনাল শৃঙ্খলা প্রযোজ্য। মূল উদ্দেশ্য হলো এটি দেখানো যে রাউটিং, স্যুইচিং এবং ফায়ারওয়াল পলিসি কাঙ্ক্ষিত আইসোলেশনের সাথে সামঞ্জস্যপূর্ণ।

আপনি যখন একজন অ্যাসেসরের জন্য এটি লিখবেন, আর্টিফ্যাক্টগুলো একসাথে রাখুন - টেস্ট প্ল্যান, টেস্ট ফলাফল, প্রতিকার নোট, এবং পুনরায় পরীক্ষার প্রমাণ। সেই বান্ডিলটি "আমরা মনে করি এটি বিচ্ছিন্ন" বাক্যটিকে "আমরা এটি প্রমাণ করেছি"-তে রূপান্তরিত করে।

PCI ওয়্যারলেসের জন্য সঠিক অ্যাথেন্টিকেশন মডেল নির্বাচন করা

শেয়ার করা পাসওয়ার্ড হলো সবচেয়ে দুর্বল গ্রহণযোগ্য সমাধান, এবং বাস্তব অপারেশনের অধীনে এটি ভেঙে ফেলা সাধারণত সবচেয়ে সহজ। কর্মী পরিবর্তন হয়। ঠিকাদাররা চলে যায়। কনসেশন রোটেট হয়। দীর্ঘদিন ধরে ব্যবহৃত একটি PSK একটি ঝুঁকিতে পরিণত হয়, এমনকি ওয়্যারলেস সিগন্যাল নিজেই সেগমেন্ট করা থাকলেও। PCI পরিবেশের জন্য, অ্যাথেন্টিকেশনকে অবশ্যই অনন্য অ্যাক্সেস, টার্গেটেড রিভোকেশন এবং পরিষ্কার আইডেন্টিটি ম্যাপিং সমর্থন করতে হবে।

এখানে সরাসরি তুলনা দেওয়া হলো।

Model	Shared Secret ঝুঁকি	Per-Device Revocation	VLAN Mapping-এ Identity	PCI 4.0.1 উপযুক্ততা
Shared PSK	উচ্চ, একটি গোপন কী অনেক ব্যবহারকারী বা ডিভাইসে শেয়ার করা হয়	দুর্বল, একজন ব্যবহারকারীকে পরিবর্তন করা মানে সাধারণত পুরো কী পরিবর্তন করা	সীমিত, পরিচয় অস্পষ্ট হয়ে যায়	কর্মী এবং অপারেশনাল নেটওয়ার্কের জন্য অনুপযোগী
EAP-TLS সহ WPA2-Enterprise	কম, ক্রডেনশিয়ালগুলি ডিভাইসের সার্টিফিকেটের সাথে যুক্ত থাকে	শক্তিশালী, WLAN পুনর্নির্মাণ না করেই একটি সার্টিফিকেট বাতিল করা যেতে পারে	শক্তিশালী, RADIUS ব্যবহারকারী এবং ডিভাইসগুলিকে পলিসিতে ম্যাপ করতে পারে	কর্মীদের অ্যাক্সেসের জন্য অত্যন্ত উপযোগী
Per-device xPSK	Shared PSK-এর চেয়ে কম, প্রতিটি ডিভাইস বা টেন্যান্ট নিজস্ব কী পায়	শক্তিশালী, অন্যদের প্রভাবিত না করে একটি কী সরানো যেতে পারে	ভালো, পরিচয় পলিসি এবং বাতিলকরণ পরিচালনা করতে পারে	BYOD, IoT, কনসেশনের জন্য অত্যন্ত উপযোগী

EAP-TLS সহ WPA2-Enterprise কর্মীদের জন্য সবচেয়ে পরিচ্ছন্ন মডেল। এটি আপনাকে সার্টিফিকেট ভিত্তিক বিশ্বাস প্রদান করে এবং অডিটররা অপছন্দ করেন এমন শেয়ার্ড সিক্রেট বিশৃঙ্খলা দূর করে। BYOD, IoT, বা কনসেশন ডিভাইসের জন্য, ডিভাইস-প্রতি বা টেন্যান্ট-প্রতি xPSKs একটি উন্নত অপারেশনাল উপযুক্ততা প্রদান করে, কারণ আপনি পুরো নেটওয়ার্ক বন্ধ না করেই একটি ডিভাইস রিভোক করতে পারেন।

অপারেশনাল নিয়ম: আপনি যদি অন্য সবার অ্যাক্সেস পরিবর্তন না করে একটি ডিভাইস রিভোক বা বাতিল করতে না পারেন, তবে মডেলটি অত্যন্ত স্থূল।

আইডেন্টিটি-ভিত্তিক ডিজাইনের জন্য, Purple Access'র আইডেন্টিটি-ভিত্তিক নেটওয়ার্কিং পৃষ্ঠাটি পর্যালোচনা করা উচিত কারণ এটি একটি একক শেয়ার করা ক্রিডেনশিয়ালের পরিবর্তে ব্যবহারকারী এবং ডিভাইসের পরিচয়ের ওপর ভিত্তি করে ওয়্যারলেস অ্যাক্সেস তৈরি করে। এটি বহু-সাইট এস্টেটে pci compliance wifi-এর জন্য সঠিক মানসিক মডেল।

গেস্ট WiFi-এর একটি ডেডিকেটেড পাথে থাকা উচিত যার সাথে CDE-এর কোনো রুট থাকবে না। স্টাফ অ্যাক্সেসে সার্টিফিকেট ব্যবহার করা উচিত। বাকি সব কিছু স্পষ্ট, বাতিলযোগ্য এবং নিরীক্ষণযোগ্য হতে হবে।

আইডেন্টিটি ড্রিভেন VLAN, Cloud RADIUS এবং শক্তিশালী ক্রিপ্টোগ্রাফি

প্রমাণীকরণ কেবল তখনই সাহায্য করে যখন RADIUS সঠিক সেগমেন্টে পরিচয় ম্যাপ করে। PCI ওয়্যারলেস ডিজাইনে, কন্ট্রোল পাথটি পরিচয় স্টোর থেকে RADIUS হয়ে VLAN থেকে ফায়ারওয়াল পলিসি পর্যন্ত চলে, এবং প্রতিটি হ্যান্ডঅফ যাচাইযোগ্য হতে হবে।

আইডেন্টিটিকে সঠিক স্থানে পৌঁছাতে হবে

Microsoft Entra ID, Okta, বা Google Workspace-এর মতো সিস্টেমের মাধ্যমে ডিরেক্টরি-ব্যাকড প্রভিশনিং নতুন, স্থানান্তরিত এবং প্রস্থানকারী কর্মীদের পলিসির সাথে মানানসই রাখে। যদি আইডেন্টিটি পরিবর্তিত হয় কিন্তু VLAN অ্যাসাইনমেন্ট না হয়, তবে নেটওয়ার্ক নতুন পরিস্থিতিতেও পুরানো ব্যবহারকারীর মতোই আচরণ করে।

মূল সুইচিং লেয়ারের জন্য VLAN setup for small business দেখুন, যা ট্রাঙ্ক এবং অ্যাক্সেস-পোর্ট কনফিগারেশন কভার করে যা এই RADIUS-assigned সেগমেন্টগুলো পরিচালনা করে।

যখন আপনার বিভিন্ন অঞ্চল বা সাইট জুড়ে ধারাবাহিক অথেন্টিকেশনের প্রয়োজন হয়, তখন Cloud RADIUS এই মডেলের সাথে সামঞ্জস্যপূর্ণ হয়। Purple Access এর Cloud RADIUS সঠিক SSID এবং VLAN এর সাথে আইডেন্টিটি চালিত রাউটিংকে সংযুক্ত করে, সাথে অডিট লগিং এবং রিভোকেশন সহায়তা প্রদান করে। এটি ওয়্যারলেস অ্যাক্সেসকে স্ট্যাটিক MAC তালিকার পরিবর্তে বর্তমান আইডেন্টিটির সাথে যুক্ত রাখে।

শক্তিশালী ক্রিপ্টোগ্রাফি স্কোপের বিবরণের একটি অংশ

PCI ওয়্যারলেস নির্দেশিকা কার্ডহোল্ডার ডাটা ট্রানজিশনের জন্য ওয়্যারলেস নেটওয়ার্কগুলোকে পাবলিক নেটওয়ার্ক হিসেবে গণ্য করে, তাই PAN ট্রাফিকের জন্য TLS, IPsec, অথবা WPA2-AES-এর মতো শক্তিশালী ক্রিপ্টোগ্রাফি প্রয়োজন (PCI Wireless Guidelines)। "সুরক্ষিত WiFi" আর কমপ্লায়েন্ট WiFi এক জিনিস নয়। লিঙ্কের মাধ্যমে ট্রান্সমিট হওয়া ডাটার সাথে ক্রিপ্টো নির্বাচন মানানসই হতে হবে।

MDM এর মাধ্যমে সার্টিফিকেট ভিত্তিক অনবোর্ডিং শেয়ার্ড পাসওয়ার্ড থেকে প্রাইভেট কী সরিয়ে রাখে এবং কর্মীদের ডিভাইসগুলিকে একটি পরিচ্ছন্ন ট্রাস্ট মডেল দেয়। মিশ্র এস্টেটের জন্য, কর্মচারীদের জন্য সার্টিফিকেট, সম্পূর্ণ এন্টারপ্রাইজ অথেন্টিকেশন চালাতে পারে না এমন ডিভাইসগুলির জন্য xPSKs এবং পেমেন্ট সিস্টেমে কখনোই পৌঁছায় না এমন একটি পাথে গেস্ট অ্যাক্সেস ব্যবহার করুন।

লগিং, মনিটরিং এবং রোগ অ্যাক্সেস পয়েন্ট সনাক্তকরণ

একটি লিখিত নো-WiFi পলিসি রগ-ডিটেকশন (rogue-detection) বাধ্যবাধকতা দূর করে না। PCI প্রত্যাশা করে যে প্রতিষ্ঠানগুলো অনুমোদিত এবং অননুমোদিত উভয় ওয়্যারলেস অ্যাক্সেস পয়েন্ট পরিচালনা করবে, তাই কন্ট্রোলটি কেবল ডকুমেন্টেশনের মধ্যে সীমাবদ্ধ না রেখে সক্রিয় হতে হবে।

যে মনিটরিং সাইকেলটি কার্যকর

একটি অনুমোদিত AP ইনভেন্টরি দিয়ে শুরু করুন, তারপর এটিকে একটি লাইভ কন্ট্রোল রেকর্ড হিসেবে বিবেচনা করুন। এর মধ্যে মালিক, অবস্থান, হার্ডওয়্যার অ্যাড্রেস, SSIDs, কন্ট্রোলার, ফার্মওয়্যার এবং AP-টি CDE-তে পৌঁছাতে পারে কিনা তা অন্তর্ভুক্ত করুন। একটি নির্দিষ্ট সাপ্তাহিক ক্রমানুসারে ইনভেন্টরি তুলনা পরিচালনা করুন এবং ডিফ (diff) আউটপুট সংরক্ষণ করুন, কারণ অ্যাসেসর জিজ্ঞাসা করবেন শেষ তুলনা কখন চলেছে এবং এতে কী পাওয়া গেছে।

কন্ট্রোলার ডেটা, সুইচ ডেটা, DHCP ডেটা এবং ওয়্যারলেস ইন্ট্রুশন ডিটেকশন আউটপুট-এর সাথে সেই ইনভেন্টরি তুলনা করুন। তারপর অমিল খুঁজুন: একটি নতুন BSSID, একটি স্থানান্তরিত ডিভাইস, ফার্মওয়্যার অমিল, অথবা এমন একটি AP যা একটি সোর্সে দেখা যাচ্ছে কিন্তু অন্যদের মধ্যে নেই।

যদি আপনি একটি অজানা BSSID দেখতে পান, তবে এটি তদন্ত করুন। ডিভাইসটি শারীরিকভাবে যাচাই করুন, শ্রেণীবদ্ধ করুন এবং এটি অননুমোদিত হলে কোয়ারেন্টাইন বা অপসারণ করুন। সতর্কবার্তা, তদন্তের নোট এবং প্রতিকারের প্রমাণ রাখুন। অ্যাসেসর একটি স্পষ্ট ট্রেইল চান, কেউ এটি পরিচালনা করেছে এমন একটি বাক্য নয়।

একটি ব্যবহারিক ওয়্যারলেস মনিটরিং সাইকেল এইরকম হওয়া উচিত:

• প্রথমে ইনভেন্টরি করুন: মালিকানা এবং অবস্থানসহ অনুমোদিত তালিকাটি সর্বদা আপডেট রাখুন।
• সময়সূচী অনুযায়ী ক্রস চেক করুন: প্রতি সপ্তাহে কন্ট্রোলার, সুইচ, DHCP এবং WIDS ডাটা তুলনা করুন।
• অপরিচিত বিষয়গুলো উর্ধ্বতনদের জানান: ইনভেন্টরির সাথে মেলে না এমন যেকোনো BSSID বা AP তদন্ত করুন।
• স্বশরীরে যাচাই করুন: ডিভাইসটি শ্রেণীবদ্ধ করার আগে শারীরিকভাবে নিশ্চিত করুন।
• প্রতিকার করুন এবং সংরক্ষণ করুন: ডিভাইসটিকে কোয়ারেন্টাইন বা অপসারণ করুন, তারপর অ্যালার্ট ট্রেইল এবং তুলনামূলক আউটপুট সংরক্ষণ করুন।

ডায়াগ্রামিং স্ট্যান্ডার্ডের কথা ভুলে যাবেন না

ওয়্যারলেস ডায়াগ্রামগুলোতে সিকিউরিটি কন্ট্রোল প্লেসমেন্ট এবং আউট-অফ-স্কোপ WLAN সহ সমস্ত প্রাসঙ্গিক সংযোগ দেখানো উচিত। একজন অ্যাসেসরের দেখা প্রয়োজন যে ওয়্যারলেস ফ্যাব্রিক কীভাবে CDE-এর সাথে সম্পর্কিত, কেবল SSIDs কোথায় সম্প্রচারিত হচ্ছে তা নয়।

আপনার মনিটরিং যদি কেবল তা-ই রিপোর্ট করে যা আপনি স্থাপন করতে চেয়েছিলেন, তবে ফ্লোরে কী আবির্ভূত হয়েছে তা এটি মিস করবে।

সবচেয়ে সাধারণ ওয়্যারলেস PCI ফাইন্ডিংয়ের জন্য রেমিডিয়েশন প্লেবুক

বেশিরভাগ ওয়্যারলেস ফাইন্ডিং বারবার ফিরে আসে কারণ টিমগুলো কন্ট্রোল ব্যর্থতার সমাধান না করে লক্ষণের চিকিৎসা করে। তারা একটি ডায়াগ্রাম ঠিক করে, পাসওয়ার্ড পরিবর্তন করে, বা কন্ট্রোলার প্যাচ করে, তারপর এভিডেন্স চেইন পুনরায় তৈরি করার আগেই থেমে যায়। সেই কারণেই মাল্টি-সাইট অডিটে একই সমস্যা বারবার দেখা দেয়।

ত্রুটিটি সমাধান করুন, তারপর সমাধানের প্রমাণ দিন

যদি কোনও নেটওয়ার্ক পরিবর্তনের পর সেগমেন্টেশন ব্যর্থ হয়, তবে আইসোলেশন টেস্টগুলি পুনরায় চালান এবং ফলাফল রেকর্ড করুন। যদি কর্মীরা এখনও একটি পাসওয়ার্ড শেয়ার করে থাকেন, তবে তাদের সার্টিফিকেট বা ডিভাইস-প্রতি কীতে স্থানান্তর করুন। যদি কন্ট্রোলার বা সুইচ কনফিগ বিচ্যুত হয়, তবে সেগুলিকে নীতিতে ফিরিয়ে আনুন এবং তারিখের ট্রেইল সহ নতুন স্ন্যাপশট সংরক্ষণ করুন।

কন্ট্রোলার বা সুইচের দুর্বল অ্যাডমিনিস্ট্রেটিভ পাথের ক্ষেত্রেও একই ব্যবস্থার প্রয়োজন। এটি বন্ধ করুন, তারপর একজন আক্রমণকারী যে দৃষ্টিকোণ ব্যবহার করবে সেখান থেকেই এটি বন্ধ রয়েছে তা প্রমাণ করুন। লাইভ পাথ থেকে তথ্য লিক হলে নির্দিষ্ট ACL বিদ্যমান থাকা সত্ত্বেও অ্যাসেসর সেটি বিবেচনা করবেন না।

অডিট ইমপ্যাক্ট অনুযায়ী ব্যাকলগকে অগ্রাধিকার দিন

1. যেকোনো নেটওয়ার্ক পরিবর্তনের পর সেগমেন্টেশন প্রমাণ করুন। এটি সবচেয়ে গুরুত্বপূর্ণ সমাধান কারণ এটি মূল PCI প্রশ্নের উত্তর দেয় - ওয়্যারলেস কি CDE-তে পৌঁছাতে পারে?
2. শেয়ার করা পাসওয়ার্ড পরিবর্তন করুন। শেয়ার করা অ্যাক্সেস সঠিকভাবে বাতিল করা কঠিন এবং স্কেলে পরিচালনা করা সহজ নয়।
3. ফার্মওয়্যার এবং কনফিগারেশন আপডেট করুন। ড্রাফটের কারণেই গতকালের অনুগত ডিজাইন আজকের ঝুঁকিতে পরিণত হয়।
4. অননুমোদিত AP প্রতিক্রিয়া নথিভুক্ত করুন। প্রতিক্রিয়া রেকর্ড না করা হলে, নিয়ন্ত্রণটি কাল্পনিক মনে হয়।
5. পুনরায় অডিট করুন এবং প্রাপ্ত ফলাফলগুলো সমাধান করুন। প্রতিটি সমাধানের জন্য পুনরায় পরীক্ষার প্রমাণের প্রয়োজন, অন্যথায় এটি সমাধান হিসেবে গণ্য হয় না।

সেরা প্রতিকারের প্রমাণগুলো সাধারণ হয়। এটি পরিবর্তন, পরীক্ষা, ফলাফল এবং তারিখ দেখায়। অডিটররা এটিকেই বিশ্বাস করেন।

ওয়্যারলেস সম্পর্কে অ্যাসেসররা কী জিজ্ঞাসা করেন

গেস্ট WiFi নিজে থেকেই PCI স্কোপ দূর করে না। অ্যাসেসররা কেবল নেটওয়ার্ক ডায়াগ্রামে নয়, বাস্তবে ওয়্যারলেস ট্র্যাফিক যে CDE-তে পৌঁছাতে পারে না তার প্রমাণ খুঁজেন।

তারা প্রমাণ চান, লেবেল নয়। এর অর্থ হলো ফায়ারওয়াল রুল, রাউটিং রিভিউ, কন্ট্রোলার এবং সুইচ স্ন্যাপশট, প্যাকেট টেস্ট এবং লগ যা দেখায় যে ট্র্যাফিক ডিজাইন অনুযায়ী ব্লক বা সীমিত করা হয়েছে। একটি পৃথক SSID কেবল তখনই দরকারী যদি লাইভ পাথ সেটিকে সাপোর্ট করে।

তারা রিটেস্ট ট্রেইলও পরীক্ষা করেন। নেটওয়ার্ক, ফায়ারওয়াল, কন্ট্রোলার, VLAN, আইডেন্টিটি, বা পেমেন্ট-অ্যাপ্লিকেশনে উল্লেখযোগ্য পরিবর্তনের পর ওয়্যারলেস সেগমেন্টেশন টেস্টিং পুনরায় করা উচিত, এবং অ্যাসেসর সর্বশেষ রিটেস্টের প্রমাণ দেখতে চাইবেন।

একটি কন্ট্রোলার বা ফায়ারওয়াল পরিবর্তনের পর, ওয়্যারলেস পরীক্ষাগুলো পুনরায় চালান এবং আগের ও পরের ফলাফলগুলো একসাথে রাখুন। যদি কন্ট্রোল পরিবর্তিত হয়, তবে প্রমাণকেও এর সাথে পরিবর্তিত হতে হবে।

মাল্টি-সাইট সেটআপগুলি অতিরিক্ত যাচাইয়ের আওতায় আসে। শেয়ার করা ইনফ্রাস্ট্রাকচার গেস্ট, স্টাফ এবং পেমেন্ট ট্র্যাফিককে অস্পষ্ট করে তুলতে পারে, তাই অ্যাসেসররা সাধারণত সমস্ত সাইট জুড়ে আইডেন্টিটি ম্যাপিং, সেগমেন্টেশনের প্রমাণ এবং লাইভ মনিটরিংয়ের দাবি করেন। তারা সাধারণত শেষ তিনটি rogue-AP তদন্তের রেকর্ড এবং সাম্প্রতিকতম ফায়ারওয়াল পরিবর্তন পুনরায় পরীক্ষা করা হয়েছে এমন প্রমাণও চেয়ে থাকেন।

Purple Access পরিচয়ের ওপর ভিত্তি করে ওয়্যারলেস অ্যাক্সেস মডেল তৈরি করতে, RADIUS-চালিত পলিসির সাহায্যে ব্যবহারকারী ও ডিভাইসগুলোকে সেগমেন্ট করতে এবং অডিট প্রমাণ এক জায়গায় রাখতে সাহায্য করে। আপনি যদি একাধিক সাইটজুড়ে pci compliance wifi আরও সুরক্ষিত করতে চান, তবে Purple Access ভিজিট করুন এবং দেখুন কীভাবে এর Cloud RADIUS, xPSK, এবং এভিডেন্স টুলিং একটি নিয়ন্ত্রিত ওয়্যারলেস ডিজাইনে মানিয়ে যায়।