Layer 3.5 (Industrial DMZ - IDMZ) and OT Cybersecurity

 

ပြီးခဲ့တဲ့ Post မှာ Purdue Model ရဲ့ Layer 0 ကနေ Layer 5 အထိ အခြေခံ စနစ်တွေကို ရှင်းပြခဲ့ပြီးပါပြီ။

မဖတ်ရသေးရင် ဒီအောက်က လင့် တွေ မှာ ဖတ်နိုင်ပါတယ်။

https://www.ictformyanmar.com/2026/09/it-network-vs-ot-network.html

https://www.ictformyanmar.com/2026/09/purdue-model-for-ot-network.html

ဒီနေ့မှာတော့ OT Network (Industrial Network) တွေကို ကာကွယ်ပေးဖို့ ဘာကြောင့် Industrial DMZ (IDMZ / Layer 3.5) ကို မဖြစ်မနေ လိုအပ်တာလဲဆိုတာကို ကမ္ဘာကျော် OT Cyberattacks ဖြစ်စဉ် နှစ်ခုနဲ့အတူ ဝေမျှပေးချင်ပါတယ်။

ကမ္ဘာကျော် OT Cyberattacks ဖြစ်စဉ်များ

-------------------------------------------------

၁) Stuxnet Attack (2010, Iran) – Air-gapped Physical Vector Attack

အီရန်နိုင်ငံ Natanz ယူရေနီယမ်သန့်စင်စက်ရုံမှာ OT Network (Layer 0–3) နဲ့ IT Network (Layer 4–5) တို့ကို လုံးဝ Physical အဆက်အသွယ်ဖြတ်တောက်ထားတဲ့ (Air-gapped) စနစ်ကို သုံးထားတာပါ။

ဒါပေမဲ့ Attacker တွေဟာ Layer 3 မှာရှိတဲ့ Engineering Workstations တွေဆီ Infected USB Flash Drive ကနေတစ်ဆင့် Stuxnet Malware ဝင်ရောက်အောင် ပြုလုပ်ခဲ့ပြီး  Layer 0 မှာရှိတဲ့ Centrifuges မော်တာတွေကို Physically ပျက်စီးသွားအောင် တိုက်ခိုက်ခဲ့ပါတယ်။

မော်တာတွေကို ပျက်စီးအောင်လုပ်ရုံသာမကပဲ  Malware က မော်တာတွေ ပုံမှန်လည်ပတ်နေစဉ် ၂ မိနစ်စာ Data ကို ကြိုတင် Record လုပ်ထားပြီး အပေါ် Layer တွေရဲ့ Monitoring Screens တွေပေါ်မှာ ပုံမှန်လည်ပတ်နေသယောင် လှည့်စား (Replay Attack) ခဲ့ပါတယ်။ 

ဒီ Attack ကြောင့် အီရန်ရဲ့ နူကလီးယားစီမံကိန်း ရေရှည် အဟန့်အတား ဖြစ်ခဲ့ရပါတယ်။

ဒီဖြစ်ရပ်ကနေ ပဲ တကမ္ဘာလုံး အတိုင်းအတာနဲ့ Physical USB Drive တွေရဲ့ အန္တရာယ်ကို သတိပြုမိစေခဲ့ပြီး Removable Media Control နဲ့ OT Network Visibility တို့ရဲ့ အရေးပါမှုကို မီးမောင်းထိုးပြခဲ့ပါတယ်။

၂) Ivano-Frankivsk Power Grid Attack (2015, Ukraine) – IT-to-OT Pivoting Attack

ဒီဖြစ်စဉ်ကတော့ ယူကရိန်းနိုင်ငံ၊ Ivano-Frankivsk မြို့ မှာ ရှိတဲ့ Power Substation တစ်ခုမှာ ဖြစ်ပွားခဲ့တာပါ။

Attacker တွေဟာ Power Station ရဲ့ IT Network ထဲကို Spear-phishing Email ကနေတစ်ဆင့် စတင်ဝင်ရောက်ခဲ့ပါတယ်။ ဝင်ရောက်ပြီးတာနဲ့ ဝန်ထမ်းတွေရဲ့ Login Credentials (VPN & System Access) တွေကို ခိုးယူပြီး OT/SCADA Network ထဲကိုတိုက်ရိုက် Pivot လုပ်ဝင်ရောက်၊  Substation Breakers တွေကို Remote ကနေ shutdown လိုက်တာကြောင့် မြို့ထဲက လူဦးရေ ၂ သိန်းကျော် ၁ နာရီကျော်ကြာ လျှပ်စစ်မီး ပြတ်တောက်ခဲ့ရပါတယ်။

ဒီ ဖြစ်ရပ်ကနေ ပဲ IT Network ကနေ OT Network ထဲကို တိုက်ရိုက် မဝင်ရောက်နိုင်အောင် ခိုင်မာတဲ့ Strict IDMZ Architecture လိုအပ်ကြောင်း အဓိက သက်သေပြခဲ့ပါတယ်။

အဲဒီတော့  IDMZ (Layer 3.5) ဆိုတာ ဘာလဲ။ ဘယ်လိုမျိုးလဲ။

IDMZ ဆိုတာ OT Zone (Layer 0–3) နဲ့ Enterprise IT Zone (Layer 4–5) ကြားမှာ ကြားခံအဖြစ် ခြားနားထားတဲ့ Buffer Zone (သို့မဟုတ်) Sanitizing Security Boundary တစ်ခု ဖြစ်ပါတယ်။

သမားရိုးကျ Network တွေမှာ IT နဲ့ OT ကို တိုက်ရိုက် Direct Connection ချိတ်ဆက်တာမျိုး လုံးဝ မလုပ်ရပါဘူး။ IT နဲ့ OT အကြား ဖြတ်သန်းမယ့် Data တွေ၊ Services တွေအားလုံးကို IDMZ (Layer 3.5) မှာတင် ရပ်တန့်စေပြီးမှ စစ်ဆေး အလုပ်လုပ်စေတာ ဖြစ်ပါတယ်။

ဒါဆိုရင် IT နဲ့ OT ကို လုံးဝ Air-gap လုပ်ထားလို့ မရဘူးလား။

မရပါဘူး။ ဘာကြောင့်လဲဆိုတော့ Layer 4 နဲ့ Layer 5 မှာ Business Intelligence Data နဲ့ Telemetry Data တွေ လိုအပ်လို့ပါပဲ။ Sub-contractor/Vendors တွေအနေနဲ့ Monitoring & Maintenance လုပ်ဖို့လိုသလို၊ ကုမ္ပဏီအနေနဲ့လည်း Business Strategy နဲ့ Daily Operations တွေ အတွက် Real-time and historical data တွေ လိုအပ်လို့ ဖြစ်ပါတယ်။

ဒါဆို Safe, Secure ဖြစ်ပြီး Business Operations မထိခိုက်အောင် IT နဲ့ OT ကို ဘယ်လို Isolate လုပ်ကြမလဲ။

အောက်ပါ နည်းလမ်းများကို ပေါင်းစပ်အသုံးပြုကြပါတယ်။

- Data Diode ဖြင့် Physical Boundary ခံယူခြင်း

OT Layer 2/3 က Telemetry Data များကို IT Layer 4/5 သို့ ပို့သည့်အခါ IDMZ (Layer 3.5) တွင် Data Diode (Hardware-enforced One-Way Data Flow) ခံထားခြင်း။ ဒါဆိုရင် IT Network ဘက်ကနေ OT ထဲကို Inbound Traffic တိုက်ရိုက် စီးဆင်း၍ မရတော့တာကြောင့် ယူကရိန်း Power Grid လိုမျိုး  IT Network က တစ်ဆင့် Attack လုပ်မှုကို ထိရောက်စွာ ကာကွယ်နိုင်သွားပါတယ်။

- OT Native IDS ဖြင့် Real-time Monitoring ပြုလုပ်ခြင်း

OT Zone (Layer 2/3) Switch တွေမှာNozomi Networks, Gigamon, Claroty, Dragos တို့ လို Industrial Control Vendor တွေ ရဲ့ OT Native IDS တပ်ပြီး Anomaly Detection & Monitoring လုပ်တာမျိုး။

ဒါဆိုရင် Stuxnet လိုမျိုး ပုံမှန်မဟုတ်တဲ့ PLC Logic Upload/Download activity၊ suspicious Remote Desktop (RDP) Access တွေ နဲ့ Unauthorized SCADA Commands တွေကို  Real-time Detect & Alert လုပ်ပေးနိုင်ပါတယ်။

- IDMZ (Layer 3.5) မှာ ဘာ Servers/Services တွေ ရှိသင့်သလဲ။

IT ဘက်ကနေ OT Systems တွေကို Remote Access လုပ်မယ်ဆိုရင် IDMZ ထဲရှိ Jump Host မှတစ်ဆင့်သာ ဝင်ရောက်စေပြီး MFA နှင့် Just-In-Time (JIT) Access Controls များ ထားရှိခြင်း။

 IT Network ကနေ OT Network ထဲက Historian Server ထဲမှာရှိတဲ့ Logs/Data တွေကို တိုက်ရိုက် မကြည့်စေဘဲ IDMZ ထဲတွင် Replica Server ထားခြင်း။

OT Layer 2/3 ထဲက Systems တွေ အတွက် Antivirus Definitions နဲ့ Firmware/OS Patches တွေကို delivery လုပ်ဖို့ အတွက် IDMZ ထဲမှာ Update Server ထားပြီး Patch delivery အမြဲလုပ်ခြင်း တို့ပဲ ဖြစ်ပါတယ်။

အနှစ်ချုပ် ပြောရမယ်ဆိုရင်

Cyberattacks တွေထဲမှာ OT Cyberattack တွေဟာ Critical Infrastructure တွေဖြစ်တဲ့ Power Stations, Water Treatment, Oil & Gas, Healthcare, Transportation (Airport, Railway) စတဲ့ စနစ်များကို ရပ်တန့်/ပျက်စီးစေပြီး လူတွေရဲ့ အသက်အန္တရာယ်ကိုပါ တိုက်ရိုက် ခြိမ်းခြောက်နိုင်တာကြောင့် 

Operational Technology Network အကြောင်း အခြေခံ သဘောတရားများကို သေချာ နားလည်ပြီး စနစ်တကျ ကာကွယ်နိုင်ကြပါစေကြောင်း အကြံပြုရင်း OT Network နဲ့ OT Cybersecurity အကြောင်းကို ဒီမှာပဲ နိဂုံးချုပ်လိုက်ပါတယ်။

(Hospital Network တွေ မှာ လုပ်ခဲ့ တုန်းက သိခဲ့ တဲ့ IoMT (Internet of Medical Things နဲ့ OT အကြောင်းတွေ ကို ရေးချင်သေးပေးမယ့် အချိန် မပေးနိုင်တော့လို့ မရေးတော့ပါဘူး။)

ပျော်ရွှင်ပါစေဗျာ။

(Be knowledgeable, pass it on then)

Purdue Model for OT Network

IT Network မှာ OSI 7 Layers ရှိသလိုပဲ၊ OT Network မှာလည်း Layer တွေ ခွဲခြားသတ်မှတ်ပေးထားတဲ့ Purdue Model ဆိုတာ ရှိပါတယ်။

OT Network ကို စီမံခန့်ခွဲမယ့်သူ သို့မဟုတ် Security ပိုင်း လုပ်ဆောင်မယ့်သူဆိုရင် Purdue Model ကို သေချာ နားလည်ထားဖို့ လိုအပ်ပါတယ်။

Layer 0: Physical Process

ဒီ Level မှာ Sensors, Actuators, Motors, Valves, Pumps တွေ အလုပ်လုပ်ပါတယ်။

ဥပမာ - ရေသန့်စက်ရုံတစ်ခုမှာ ပိုးသတ်ဆေး ထည့်တဲ့ လုပ်ငန်းစဉ်အတွင်း ပိုးသတ်ဆေး ပမာဏကို တိုင်းပေးတဲ့ Sensors တွေနဲ့ သတ်မှတ်ပမာဏ ရောက်တဲ့အခါ ဆေးထည့်တာ ရပ်တန့်ဖို့ ထိန်းချုပ်ပေးတဲ့ Valves တွေ အလုပ်လုပ်တာမျိုး ဖြစ်ပါတယ်။

Layer 1: Basic Control

ဒီ အပိုင်းမှာ PLCs (Programmable Logic Controllers), RTUs (Remote Terminal Units), IEDs (Intelligent Electronic Devices) တွေ ရှိပြီး Layer 0 မှာ အလုပ်လုပ်နေတဲ့ Physical Equipment တွေကို တိုက်ရိုက် ထိန်းချုပ်ခိုင်းစေတာပါ။

ဥပမာ - Shopping Mall တွေက Lift တွေ၊ Escalator တွေရဲ့ အမြန်နှုန်းနဲ့ အတက်အဆင်း Logic တွေကို PLC ထဲမှာ ရေးသွင်းထားပြီး အလိုအလျောက် အလုပ်လုပ်စေတာမျိုး ဖြစ်ပါတယ်။

Layer 2: Area Control (Supervisory Control)

ဒီ Layer ကတော့ HMIs (Human Machine Interfaces), SCADA Software, Engineering Workstations, Control Rooms တွေနဲ့ စနစ်တစ်ခုလုံးကို စောင့်ကြည့်တာနဲ့ ထိန်းချုပ်တဲ့ နေရာပါ။

ဒီအပိုင်းမှာ လူ Operator က ဝင်ရောက်ကြည့်ရှုပြီး လိုအပ်သလို ထိန်းချုပ်မှုများ ပြုလုပ်ပေးနိုင်ပါတယ်။

ဥပမာ - Lift ၄ စင်း Run နေတဲ့ Mall တစ်ခုမှာ မနက် 9 နာရီကနေ 10 နာရီအတွင်း လူအတက် ပိုများတာကို Control Room (HMI/SCADA) ကနေ တွေ့ရှိရတယ် ဆိုပါစို့။ ဒါဆိုရင် Lift အတက်/အဆင်း Mode တွေကို ပြောင်းလဲဖို့ သို့မဟုတ် Lift Controller Program တွေကို Engineering Workstation ကနေ Program Logic ကို ပြင်တာမျိုးလုပ်တာပါ။

Layer 3: Site Manufacturing Operations and Control

ဒီ အပိုင်းမှာ MES (Manufacturing Execution Systems), Historian Servers, Domain Controllers, Patch Management Servers, OT Jump Hosts စတာတွေ ပါဝင်ပါတယ်။

ဒီ Layer က Layer 2 Control က နေ monitoring လုပ်နေတဲ့ နေရာတွေအားလုံးရဲ့  အခြေအနေတွေကို ပေါင်းစပ် စီမံခန့်ခွဲပေးတာ ဖြစ်ပါတယ်။ Layer 1 နဲ့ Layer 2 က ရလာတဲ့ Logging Data တွေ ၊ Process Data တွေကို Historian Server မှာ သိမ်းပြီး Operation Improvement နဲ့ Audit တွေအတွက် ပြန်လည် ဆန်းစစ်တာမျိုး ဆောင်ရွက်ပါတယ်။

Layer 4: Enterprise Business Planning and Logistics (Enterprise IT Zone)

ဒီ Layer ကတော့ Enterprise IT Network အဆင့် ဖြစ်သွားပြီး ERP (e.g., SAP), Mail Servers, Business Applications, Corporate PCs တွေ ပါဝင်လာပါပြီ။

Layer 5: Enterprise Network / External Zone (Cloud & Internet)

ဒီ အပိုင်းမှာ Cloud Infrastructure (AWS, Azure), Corporate WAN, Internet Boundary, Third-party/Vendor Portals စတာတွေ ပါဝင်ပြီး ရုံးခွဲများ၊ Vendors များနှင့် Partners တွေ နဲ့ ချိတ်ဆက်အလုပ်လုပ်တဲ့ Network Boundary ဖြစ်ပါတယ်။

ဒါတွေကတော့ Purdue Model ရဲ့ Layer အဆင့်ဆင့်ပဲ ဖြစ်ပါတယ်။

Layer 3 (OT) နဲ့ Layer 4 (IT) ကြားမှာ Physical Connection လုံးဝ မထားတဲ့ Air-Gapped Systems တွေ ရှိသလို၊ နောက်ပိုင်းမှာ Industrial DMZ (IDMZ) လို့ ခေါ်ကြတဲ့ Layer 3.5 ဆိုတာကို ထားလာကြပါတယ်။ ဘာကြောင့် ဒီလို သီးခြား ခွဲခြားထားရတာလဲ ဆိုတဲ့ OT Cybersecurity အကြောင်းအရာတွေကိုတော့ နောက် Post တွေမှာ ဆက်လက် ဝေမျှပေးသွားပါမယ်။

IT Network vs OT network

ရထားစီးဖို့ ဘူတာထဲ ကို ဝင်လိုက်တာနဲ့ Escalator, Lift, Aircon တွေ ဟာ Building Management System  (BMS) နဲ့ အလိုအလျောက် အလုပ်လုပ်နေတာ၊

ဘယ်ဖက်ကို ဦးတည်သွားမယ့် ရထားက ဘယ်အချိန်ရောက်မယ် ဆိုတာမျိုး ကို နေ့စဉ် သွားရင်းလာရင်း သတိထားမိမယ်ထင်ပါတယ်။

နောက်တခါ ခရီးသွားဖို့ လေဆိပ်ကို ရောက်တဲ့ အခါ Baggage တွေ သယ်သွားတဲ့ Conveyor တွေ၊ လေကြောင်းလိုင်းတွေရဲ့ အချိန်ဇယားတွေ သတိထားမိလားတော့ မသိဘူး။

ဆေးရုံတွေ သွားတဲ့ အခါ လူနာတွေကိုယ်မှာ တပ်ထားတဲ့ Vital sign monitor တွေမြင်ဖူးကြမှာပေါ့။

ကားလမ်းဆုံတွေ က သူ့အလိုလို အလုပ်လုပ်နေတဲ့ Traffic light တွေ ကိုတော့ မြင်ဖူးကြမှာပါ။  

နောက်တခါ TV တွေမှာ စက်ရုံထဲကစက်တွေ အလိုအလျောက်လည်ပတ်နေတာကိုလဲ တခါတရံမြင်ဖူးကြမှာပါ။

ကိုယ်သောက်နေတဲ့ရေ က်ိုသန့်စင်ဖြန့်ဖြူးပေးနေတဲ့ Water Treatment Station တွေ၊ Electricity ကို ဖြန့်ဖြူးပေးနေတဲ့ Power station တွေ လဲ သိကြမယ်ထင်ပါတယ်။

ဒီ လုပ်ငန်းစဉ်တွေကို ထိန်းကျောင်း မောင်းနှင်နေတဲ့ Industrial Control Network တခုရှိပါတယ်။ ဒါကိုပဲ Operational Technology (OT) network လို့ ခေါ်တာပါ။

လူတော်တော်များများက OT ကို IT နဲ့ ကွဲပြီး မသိကြပဲ အတူတူလို့တောင် ထင်ကြပါသေးတယ်။

တကယ်တော့ OT network က Modbus, DNP3, Profinet, BACnet တို့လို Industrial Control System တွေ အတွက် Protocol တွေ သုံးပြီး လည်ပတ်နေရတာပါ။

Factory Automation လိုနေရာမှာပဲ IT network မှာ သုံးတဲ့ Ethernet/IP ကိုသုံးတာ။

ဒီ OT system တွေ နဲ့  IT system ရဲ့ အဓိက ကွာခြားချက်ကတော့ 

IT system က အမှားခံနိုင်တယ်၊ real time မလိုပဲ second/milliseconds နောက်ကျလို့ရတယ်။

OT system မှာ မှားတာတို့ နောက်ကျတာတို့ဆိုရင် လူမြောက်များစွာ ထိခိုက်နိုင်တာ၊ ငွေကြေးပေါင်း မြောက်များစွာ ဆုံးရှံးနိုင်တာတွေ ဖြစ်ပါတယ်။

ဒါကြောင့် IT network လို Confidential အရင်လာ Integrity and Availability က နောက်ကလိုက် မဟုတ်ပဲ၊ Availability က ပထမ၊ Integrity နဲ့ Confidentiality ကနောက်မှဆိုတဲ့ OT network operation နဲ့ OT network security ကို အချိန်ရရင် OT ရဲ့ အခြေခံ

စည်းမျဉ်း Purdue Model နဲ့ အတူ ထပ်ဝေမျှပါအုံးမယ်။ 

How to mitigate MFA fatigue attack?

 

ပုံထဲကလိုမျိုး ကိုယ်မရှိနေတဲ့ နေရာ၊ ကိုယ်သုံးနေကြ အချိန်မဟုတ်ပဲ Login Approval တောင်းနေတာမျိုးကို MFA fatigue attack လို့ခေါ်ပါတယ်။

Attacker ရဲ့ ရည်ရွယ်ချက်က ရှင်းပါတယ်။ခဏခဏ ပို့ပြီး စိတ်ရှုပ်အောင်လုပ်မယ်၊ တချက်လောက် သတိလက်လွတ်ဖြစ်ပြီး Approval ပေးလိုက်မိတာနဲ့ ရှိတာ ကုန်ပြီပဲပေါ့။

ဒီတော့ ဒါမျိုး Authentication Approval Push Notification တွေကို သတိထား သေချာကြည့်ပြီး ကိုယ်ကိုယ်တိုင် တကယ် request တာသေချာမှ approve လုပ်ကြဖို့ သတိပေးချင်ပါတယ်။

ဘာလို့ ဒါမျိုး Attack လုပ်ခံရတာလဲဆိုရင်

ကိုယ့် email နဲ့ တခြား အချက်အလက်တွေ dark web ပေါ်မှာ ပေါက်ကြားထားလို့ပါ။

ဒီလိုမပေါက်ကြားဖို့က ဘာလုပ်လုပ် Register လုပ်ခိုင်းနေတဲ့ အခုခေတ်မှာ မလွယ်တော့ပါဘူး။

ကိုယ်ဘယ်လောက်လုံခြုံရေး ဂရုစိုက်ပါစေ၊ ကိုယ်သုံးနေတဲ့ service တခုခုက လုံခြုံရေးကျိုးပေါက်တာနဲ့ ကိုယ့် data လဲ ပါသွားတာပါပဲ။

ကိုယ့်အချက်အလက် ပေါက်ကြားထားလား၊ 

မထားလားသိဖို့ကတော့ Identity Protection ကိုဝယ်သုံးမှပဲ ရပါမယ်။ ဒါတောင် protection က data expose ဖြစ်ကြောင်း သတိပေးတာနဲ့ ဖြစ်တဲ့နေရာက credential တွေလိုက်ပြောင်းရတာ နဲ့ အတော် အလုပ်ရှုပ်သေးတာပါ။

အခုလို MFA fatigue attack ကို အလွယ်ဆုံး ဖြေရှင်းနည်းကတော့ Authenticator ကိုပြောင်းလိုက်တာ၊ login email ကို alias (တခြား email) နဲ့ ပြောင်းလိုက်တာပဲ ဖြစ်ပါတယ်။

The Quantum Threat Isn't Coming - It's Already Here.

ယနေ့ခေတ်သုံး Cryptography စနစ်များကို ချိုးဖျက်နိုင်သည့် Quantum Computing ပေါ်ပေါက်လာရန် နှစ်အနည်းငယ် လိုသေးသော်လည်း Cyber Criminal တွေက တော့ သူတို့လုပ်စရာရှိတာတွေကို လုပ်နေကြတာပါပဲ။

Security Expert တွေကတော့ Cyber Criminal တွေဟာ "Harvest Now, Decrypt Later" အတွက် ပြင်ဆင်နေကြတာ အတော်တောင်ကြာနေပြီဖြစ်ကြောင်း သတိပေးထားပါတယ်။

အခု ဖတ်မရသေးသော (Encrypted Data) လျှို့ဝှက်အချက်အလက်များကို စနစ်တကျ စုဆောင်းသိမ်းဆည်းထားကြပြီး နောက်ပိုင်းတွင် Quantum Computer ပေါ်ပေါက်လာမှသာ Decryption လုပ်ပြီး ဖတ်ရှုရန် ရည်ရွယ်ထားကြခြင်းဖြစ်သည်။

Quantum Computer များ ပေါ်ပေါက်လာနိုင်ခြေ ဟာ ၂၀၃၃ ခုနှစ်လောက်မှာ ၁၇% မှ ၃၄% အထိ ရှိလာနိုင်ပြီး ၊၂၀၄၄ ခုနှစ်လောက်ဆိုရင် ၇၉% အထိ မြင့်တက်သွားမည်ဟု ခန့်မှန်းထားပြီး အဆိုပါ အချိန်များကို စိုးရိမ်ရတဲ့ ကာလလို့ သတ်မှတ်ထားကြပါတယ်။

တကယ်လို့များ ကိုယ် (သို့မဟုတ်) ကိုယ်အလုပ်လုပ်နေတဲ့ အဖွဲ့အစည်း ရဲ့ Data များသည် နောက်ထပ် ၁၀ နှစ်ကျော်အထိ (Encrypt) လျှို့ဝှက်ထားရန် လိုအပ်ပါက၊ ထို Data များသည် ယနေ့ကတည်းကပင် အန္တရာယ်ရှိနေပြီဖြစ်သည်။

ကြိုတင်ပြင်ဆင်မှုများ အနေနဲ့ ကတော့
အမေရိကန်မှာဆိုရင် အစိုးရဌာနများသည် ၂၀၃၅ ခုနှစ်နောက်ဆုံးထား၍ Quantum Resistance Cryptography လုံခြုံရေးစနစ်များသို့ ပြောင်းလဲရန် သတ်မှတ်ချက်များ ရှိလာပြီဖြစ်သည်။ Government Regulator များကလဲ လုပ်ငန်းအဖွဲ့အစည်းများအနေဖြင့် အနာဂတ်အတွက် စီမံချက်များ ချမှတ်ရုံသာမက လက်ရှိတွင် မည်သို့တိုးတက်အောင် ဆောင်ရွက်နေသည်ကိုပါ သက်သေပြရန် ပိုမိုမျှော်လင့်လာကြသည်။

Feburary လအတွက် SANS Cyber Defense Insider က ဆောင်းပါးလေး သဘောကျလို့ ပြန်ဝေမျှလိုက်တာပါ။

ပျော်ရွှင်ပါစေ။

(Be knowledgeable, pass it on then)

Does your DLP ready to control the data breach (photos and videos) through cameras to AI?

AI နည်းပညာကို အသုံးပြုပြီး DLP (Data Loss Prevention) အတွက် Sensitive Data တွေကို Camera နဲ့ ရိုက်တာရော၊ Screenshot ယူတာနဲ့ ယူထားတဲ့ Data ကို AI ကို ပေးပြီး သိချင်တာတွေ မေးတာကို ထိရောက်စွာ တားဆီးလို့ ရပါတယ်။

ဒါပေမဲ့ နည်းပညာတစ်ခုတည်းနဲ့ အကုန်လုံးကို ၁၀၀% ပိတ်ဆို့ဖို့ထက် နည်းလမ်းအမျိုးမျိုးကို ပေါင်းစပ်အသုံးပြုရတာမျိုး ဖြစ်ပါတယ်။ 

ဘယ်လိုနည်းလမ်းမျိုးတွေ အသုံးပြုလို့ရနေလဲဆိုတာ အောက်မှာ အကြမ်းဖျင်းအနေနဲ့ ကြည့်ကြရအောင်ပါ။

၁။ Camera နဲ့ ဓာတ်ပုံ/ဗီဒီယို ရိုက်တာကို AI နဲ့ တားဆီးခြင်း (Physical Camera Detection)

ဒါက DLP မှာ အခက်ခဲဆုံး အပိုင်းပါ။ ဝန်ထမ်းတစ်ယောက်က သူ့ဖုန်းနဲ့ ကွန်ပျူတာ screen ကို ဓာတ်ပုံရိုက်တာကို တားဖို့အတွက် "AI-powered Human/Object Detection" ကို သုံးပါတယ်။

• Webcam Monitoring: AI ဟာ ကွန်ပျူတာရဲ့ Webcam ကနေတစ်ဆင့် အမြဲစောင့်ကြည့်နေပါတယ်။ အကယ်၍ Screen ရှေ့မှာ ဖုန်း (Smartphone) ကို မြှောက်လိုက်တာ ဒါမှမဟုတ် တခြား Camera တစ်ခုခုကို မြင်လိုက်တာနဲ့ AI က ချက်ချင်း သိရှိပါတယ်။

• Active Response: ဖုန်းကို မြင်လိုက်တာနဲ့ AI က Screen ကို ချက်ချင်း Blur (ဝါးပစ်တာ)၊ Screen ပိတ်ပစ်တာ ဒါမှမဟုတ် Admin ဆီကို Alert (သတိပေးချက်) ပို့တာမျိုး လုပ်ဆောင်ပါတယ်။

• Check Point, CyberArk သို့မဟုတ် သီးသန့် AI Privacy Software တွေမှာ ဒီလို Feature မျိုး ပါဝင်ပါတယ်။

၂။ Screenshot ယူတာကို တားဆီးခြင်း (Digital Screenshot Blocking)

ဒါကတော့ Software-based DLP တွေနဲ့ ပိုပြီး ထိရောက်အောင် လုပ်လို့ရပါတယ်။

• OS Level Blocking: DLP software တွေက Windows/macOS ရဲ့ Screenshot (PrintScreen, Snipping Tool) function တွေကို အပြီးပိတ်ထားနိုင်ပါတယ်။

• AI Content Awareness: AI က Screen ပေါ်မှာ ပေါ်နေတဲ့ Data ဟာ Sensitive ဖြစ်မဖြစ် (ဥပမာ- Credit Card နံပါတ်၊ Password၊ ဖောက်သည်စာရင်း) ကို OCR (Optical Character Recognition) နည်းပညာနဲ့ Real-time ဖတ်ပါတယ်။ Sensitive Data ဖြစ်နေရင် Screenshot ရိုက်လို့မရအောင် Automatic Block လုပ်ပေးပါတယ်။

• Invisible Watermarking: အကယ်၍ Screenshot ရိုက်သွားခဲ့ရင်တောင် AI က အစက်ကလေးတွေနဲ့ ဖော်ပြထားတဲ့ (မမြင်ရတဲ့) Watermark တွေကို ထည့်ထားပေးပါတယ်။ အဲဒီပုံကို ပြန်စစ်လိုက်ရင် ဘယ်သူ၊ ဘယ်အချိန်၊ ဘယ် IP ကနေ ရိုက်သွားတာလဲဆိုတာ ခြေရာခံလို့ ရပါတယ်။

၃။ DLP အတွက် AI ရဲ့ အဓိက အခန်းကဏ္ဍ

DLP မှာ AI ကို အောက်ပါအတိုင်း အသုံးပြုကြပါတယ်။ 

• OCR & Image Analysis: စာသားတွေတင်မကဘဲ Sensitive ဖြစ်တဲ့ ပုံစံထုတ်လုပ်ထားတဲ့ Design တွေ၊ Diagram တွေကိုပါ AI က ခွဲခြားသိမြင်ပြီး ကာကွယ်ပေးတာပါ။

• Behavioral Analytics: ပုံမှန်မဟုတ်တဲ့ အပြုအမူ (ဥပမာ- Data တွေ အများကြီးကို ဓာတ်ပုံလိုက်ရိုက်နေတာ ဒါမှမဟုတ် ခဏခဏ Screenshot ယူနေတာ) ကို AI က သံသယဖြစ်ဖွယ်အဖြစ် သတ်မှတ်ပြီး ပိတ်ဆို့ပါတယ်။

အားနည်းချက် (Limitations)

• Privacy: ဝန်ထမ်းရဲ့ Webcam ကို သုံးပြီး စောင့်ကြည့်တာမျိုးက ကုမ္ပဏီရဲ့ Privacy Policy နဲ့ ကိုက်ညီဖို့ လိုအပ်ပါတယ်။

• Hardware Speed: AI က Real-time စောင့်ကြည့်နေရတဲ့အတွက် ကွန်ပျူတာရဲ့ Performance (RAM/CPU) ကို အနည်းငယ် စားနိုင်ပါတယ်။

အပေါ်က ပြောထားတာတွေမှာ ဝန်ထမ်းရဲ့ ကိုယ်ပိုင် Phone, Tablet နဲ့ Camera ပါတဲ့ Gadget တွေကို ထိန်းချုပ်ဖို့ အတွက် မပါသေးပါဘူး။

အဲ့ဒီလို လုပ်ဖို့ အတွက်ဆိုရင် ဝန်ထမ်းရဲ့ Personal Device တွေထဲမှာ Device Management Agent ကိုထည့်သွင်းပြီး အချိန်ပြည့်စောင့်ကြည့်ရမှာဖြစ်လို့ Privacy ကို ထိပါးရမှာ ဖြစ်တာကြောင့် Data လုံခြုံရေးနဲ့ Privacy ကြားက မျဉ်းဟာ AI ခေတ်မှာ ခေါင်းခဲစရာ ကိစ္စတခုဖြစ်လို့လာနေတာပါပဲ။

အနှစ်ချုပ် အနေနဲ့

DLP အတွက်ဆိုရင်တော့ Forcepoint, Symantec DLP, သို့မဟုတ် Microsoft Purview လိုမျိုး နာမည်ကြီး DLP solution တွေမှာ AI ပါဝင်ပြီးသား ဖြစ်ပါတယ်။ သင်က အထူးသဖြင့် "Camera နဲ့ ရိုက်တာ" ကိုပဲ အဓိက တားချင်တာဆိုရင်တော့ Computer Vision (AI) သုံးတဲ့ Endpoint Privacy Software တွေကို ထည့်သွင်းစဉ်းစားသင့်ပါတယ်။

ပျော်ရွှင်ပါစေ။

(Be knowledgeable, pass it on then)

Data Loss Prevention, Insider Threat and Business Email Compromise

Company အလုပ်တွေမှာ အဖွဲ့အစည်းအပြင် ဖက်ကို  Email ပို့ရတော့ မယ်ဆိုရင် ဖြတ်သန်းရမယ့် Email Security နဲ့ Data Loss Prevention Pocess ဆိုတာရှိပါတယ်။

ဒီအဆင့်ဟာ အိုင်တီလုံခြုံရေးဝန်ထမ်း တွေ ကို တခြားဝန်ထမ်းတွေ က အထင်အမြင်လွဲမှား စေတဲ့ အဆင့်တွေ ထဲက တခုပါ။

အလုပ်မတွင်ကျယ်ဘူး။ အပိုလုပ်တယ်လို့ ထင်ကြပါတယ်။

ဒီနေရာမှာ ကျတော် ဥပမာ လေး တခု ပြောပြချင်ပါတယ်။

၂၀၁၆ ခုနှစ်၊ နိုဝင်ဘာလ မှာ Boeing ကုမ္ပဏီရဲ့ ဝန်ထမ်းတယောက် ဟာ Excel ဖိုင်တခုကို Format လုပ်ဖို့ ကြိုးစားရင်း မလုပ်တတ်တာနဲ့ အိမ်က သူ့ အမျိုးသမီးရဲ့  Personal email ဆီကို ဖိုင်ပို့ ပြီး အကူအညီလှမ်းတောင်းလိုက်ပါတယ်။

သူ မသိလိုက်တာက အဲ့ဒီဖိုင်ထဲမှာ တခြားဝန်ထမ်း ၃၆,၀၀၀ ကျော် တွေ ရဲ့  Personally Identifiable Information (PII) တွေ ပါတဲ့ Column တခု Hide ထားတယ်ဆိုတာပါပဲ။

ဒီမှာပဲ Data Protection ကျိုးပေါက် ပြီး တော့ Boeing ရဲ့ Deputy Chief Privacy Officer ကိုယ်တိုင် သက်ဆိုင်ရာ အစိုးရဌာနကို Data Breach ဖြစ်ကြောင်း အစီရင်ခံရတယ်ပေါ့။

ကံကောင်းသွားတာက Internal ဖြစ်တာရယ်၊ သိသိခြင်း အစိုးရကို အကြောင်းကြားတာရယ်ကြောင့် Boeing အနေနဲ့ သက်သာသွားတယ်ပေါ့။

သင်လဲ ကိုယ့် personal email ဆီကို အလုပ် email ကနေ ပို့တတ်တဲ့ အကျင့် ရှိရင် ဒီဥပမာကို ဖတ်ပြီး သင်ခန်းစာယူပါလို့။

Data Loss Prevention System တွေ က ကောင်းပေမယ့် Human Error ကြောင့်ဖြစ်စေ၊ Project Timeline ကြောင့်ဖြစ်စေ Data Classification, Data Labelling, Rule စတာတွေ ဟာ Perfect မဖြစ်နိုင်တဲ့ အတွက် တခါတရံမှာ Boeing လို အဖြစ်မျိုးကြုံ တဲ့ အခါ သင်ရော၊ သင်အလုပ်လုပ်နေတဲ့ ကုမ္ပဏီရော နဲ့ သင့်လုပ်ဖော်ကိုင်ဖက် အိုင်တီလုံခြုံရေး သမားတွေ အတွက် ထိခိုက်မှုတွေ ရှိလာတဲ့ အခါ နောင်တရစရာ ကိစ္စတွေ ဖြစ်လာနိုင်တာပေါ့။

Boeing ရဲ့ အဖြစ်ကို သေချာလေး သိချင်ရင်တော့ The Washington State Attorney General’s office က Public ဖွင့်ပေးထားတဲ့ အောက်က လင့်မှာ ဖတ်ကြည့်လို့ရပါတယ်။

https://agportal-s3bucket.s3.amazonaws.com/Breach%20The%20Boeing%20Company%202017-02-08.pdf

ပျော်ရွှင်ပါစေ။

(Be knowledgeable, pass it on then)

How Smart Security Teams Stay Ahead on the Rise of Deepfakes

အမေရိကန် သမ္မတ တို့၊  အီလွန်မက်စ် တို့ရဲ့ မျက်နှာနဲ့ တောင် လိမ်လာနေတဲ့ Deepfake Security Threat တွေ ဟာ Information Security သမားတွေ အတွက် ခေါင်းခဲစရာ ကိစ္စတခု ဖြစ်နေတာပါပဲ။

▪ AI Voice Detector

▪ Amber Video

▪ Arya AI

▪ Attestiv

▪ Deepware Scanner

▪ Facia

▪ FaceForensics++

▪ Hive AI

▪ Intel FakeCatcher

▪ InVID & WeVerify Toolkit

▪ Microsoft Video Authenticator

▪ OpenAI Deepfake Detector

▪ Pindrop Security

▪ Reality Defender

▪ Sensity AI (formerly Deeptrace)

▪ Serelay

စတဲ့ Deepfake AI Detection Tools တွေ ဘယ်လောက်ပဲ ရှိနေပါစေ။ လူက အဓိက ဖြစ်နေတာပါပဲ။

Tools တွေ ကလဲ စျေးကြီးတာရယ်၊ Implement လုပ်ရတာခက်တာရယ်လဲ ပါတာပေါ့။

လူက အဓိကဆိုတဲ့ နေရာမှာ အောက်မှာ ပြောပြထားတဲ့ နည်းလမ်းမျိုးတွေ နဲ့ Deepfake ကို သတိထားခွဲခြား နိုင်ပါတယ်ဆိုတာကို Security Awareness သင်တန်းတွေ မှာ ထည့်သွင်း သင်ကြားဖို့လိုပါတယ်။

Zoom, Microsoft Team or Streaming Platform ပေါ် က Video တခု ကို အကဲခတ်တဲ့ အခါမှာ Video ထဲက သူရဲ့ 

‌▪ နှုတ်ခမ်းလှုပ်ရှားမှုနှင့်အသံမကိုက်ညီခြင်း

▪ မျက်လုံးလှုပ်ရှားမှု သို့မဟုတ် မျက်တောင်ခတ်မှုပုံမှန်မဟုတ်ခြင်း 

▪ သွားများပုံမှန်မဟုတ်ဘဲ တသမတ်တည်းဖြစ်နေခြင်း 

▪ စကားပြောသည့်အခါ အသံနေအသံထားပြောင်းလဲမှုမရှိခြင်း

▪ အလင်းအမှောင် သို့မဟုတ် အရိပ်များမညီညာခြင်း

▪ မျက်လုံး၊ ပါးစပ် သို့မဟုတ် မေးရိုးတစ်ဝိုက်တွင် ဝါးနေခြင်း 

▪ လည်ပင်းနှင့်လက်တို့၏ အသားအရောင်မတူညီခြင်း 

▪ ခေါင်းလှည့်သည့်အခါ ပါး၊ မျက်ခုံး သို့မဟုတ် မေးရိုးများမညီမညာဖြစ်နေခြင်း

▪ ကိုယ်ခန္ဓာလှုပ်ရှားနေသော်လည်း ခေါင်းငြိမ်နေခြင်း သို့မဟုတ် ခေါင်းလှုပ်ရှားနေသော်လည်း ကိုယ်ခန္ဓာငြိမ်နေခြင်း  စတဲ့ အချက်တွေ နဲ့ ကိုက်ညီနေရင် Deepfake AI နဲ့ လုပ်ထားတဲ့ Video ဖြစ်နိုင်ကြောင်းပေါ့။ 

နောက် ဆုံး မှာတော့ 

▪ သံသယဖြစ်ပါက ကိုယ်နဲ့ စကားပြောနေသူကို သူပဲသိနိုင်မည့် မေးခွန်းမျိုးမေးမြန်းခြင်း ပဲ ဖြစ်ပါတယ်တဲ့။ (ဥပမာ သူနဲ့ ကိုယ်နဲ့ ထမင်းအတူတူစားတုံးက အကြောင်းအရာတခုခုကို သတိရလားမေးတာတို့ ဘာတို့ပေါ့) 

ဒါတွေ အပြင်နောက် ထပ်လုပ်နိုင်တာတွေ ကတော့ 

▪ ငွေကြေးလွှဲပြောင်းမှု တောင်းဆိုချက်တွေ ပါလာပြီ ဆိုတာနဲ့  ဒုတိယအဆင့်အတည်ပြုခြင်းဆိုတဲ့ လုပ်ထုံလုပ်နည်းဆိုင်ရာ စည်းမျဉ်းများကို အကောင်အထည်ဖော်ခြင်း (ဥပမာ ဖုန်းခေါ် ပြီး အတည်ပြု တာတို့ ၊ လူ နှစ်ယောက် အနည်းဆုံး လက်မှတ်ထိုးပေး မှ ငွေ လွှဲ လို့ ရတာတို့မျိုး ပေါ့ )

▪ Deepfake နှင့်ဆက်စပ်သောခြိမ်းခြောက်မှုများကို ဝန်ထမ်းများက သတင်းပို့နိုင်ရန်အတွက် ရှင်းလင်းပြတ်သားသော အစီရင်ခံခြင်းဆိုင်ရာ စည်းမျဉ်းများကို အကောင်အထည်ဖော်ခြင်း 

▪  Cyber Security Incident Response Plan ထဲမှာ Deepfake scenarios တွေ အတွက် အခန်းတခု ဖြည့်စွက်ထည့်ခြင်း

▪ သံသယဖြစ်ဖွယ်အကြောင်းအရာများကို စစ်ဆေးအတည်ပြုရန်၊ Online/Social Media Platform များမှ လျင်မြန်စွာဖယ်ရှားပေးရန် အတွက် အဖွဲ့တစ်ဖွဲ့ကို တာဝန်ပေးအပ်ခြင်း 

▪ ဖယ်ရှားပေးရန်တောင်းဆိုခြင်းနှင့် ရပ်တန့်ရန်အကြောင်းကြားစာများ (cease and desist letters) အတွက် နမူနာပုံစံများ ရေးဆွဲနိုင်ရန် ဥပဒေဌာနနှင့်ပူးပေါင်းဆောင်ရွက်ခြင်း 

▪ ဝန်ထမ်းများ၏ လုံခြုံရေးအသိပညာပေးလေ့ကျင့်ရေးတွင် Deepfake ခြိမ်းခြောက်မှုများကို ထည့်သွင်းသင်ကြားပေးခြင်း  တို့ပဲ ဖြစ်ပါတယ်။

ပျော်ရွှင်ပါ‌စေဗျာ။

(Be knowledgeable, pass it on then)

Dangerous Applications need to remove from your phone immediately

Cyble လို့ခေါ်တဲ့ ဆိုက်ဘာလုံခြုံရေးဆော့ဖ်ဝဲလ်ကုမ္ပဏီရဲ့ Report တခုမှာ သင့်ရဲ့  Mobile Phone ထဲမှာ တကယ့် App အစစ်တွေရဲ့ နာမည် (သို့မဟုတ်) ပုံစံတူ အတုယူထားတဲ့ App တွေ သွင်းထားတယ်ဆိုရင် ဖျက်ပစ်ဖို့ အကြံပြုထားပါတယ်။ 

ဒီအတုအယောင် Digital Wallet, Crypto Wallet App တွေဟာ ထည့်သွင်းပြီး ဖွင့်လိုက်တာနဲ့ Phishing Website (သို့မဟုတ်) In-App Browser တစ်ခုကို ဖွင့်ပေးတာကို တွေ့ရှိခဲ့ပါတယ်။

အဲဒီနောက်မှာ App တွေက သင့်ရဲ့  Digital Wallet, Crypto Wallet ကို ရှင်းထုတ်ဖို့ အသုံးပြုနိုင်တဲ့ စကားလုံးအတွဲ (mnemonic phrase) ကို တောင်းဆိုပါတယ်။ 

အဆိုပါ အတုအယောင် App တွေဟာ အသုံးပြုသူတွေကို စကားလုံးအတွဲ (mnemonic phrase) ထည့်သွင်းမိအောင် လှည့်စားဖို့အတွက် လုံခြုံမှုမရှိတဲ့ (သို့မဟုတ်) ပြန်လည်အသုံးပြုထားတဲ့ developer အကောင့်တွေကို အသုံးပြုထားပါတယ်။ 

လက်ရှိမှာတော့ Wallet အစစ်ကို တုပထားရတဲ့ Fake Wallet (၉) ခု ရှိတယ်လို့ သတိပေးထားပေမယ့် လက်ရှိတွေ့ရှိထားတဲ့ အက်ပ် ၂၀ ကျော် ရှိတာကြောင့် အဲဒီစာရင်းက တိုးလာနိုင်ပါတယ်။

ချက်ချင်းဖျက်ပစ်သင့်တဲ့ App တွေကတော့ -

Pancake Swap

Suiet Wallet

Hyperliquid

Raydium

BullX Crypto

OpenOcean Exchange

Meteora Exchange

SushiSwap

Harvest Finance Blog

တို့ပဲ ဖြစ်ပါတယ်တဲ့။

Digital Wallet, Crypto Wallet Appတွေမှာ လုံခြုံရေးစနစ် (safety net) မရှိတဲ့အတွက် ဘယ်လိုဆုံးရှုံးမှုမျိုးမဆို ပြန်လည်ရယူလို့မရပါဘူး။ ဒါကြောင့် Wallet ပိုင်ရှင်တွေက တကယ်ထုတ်ပေးတာ ဟုတ်၊ မဟုတ် သေချာပြီး တရားဝင် Website ကနေ Wallet App ကို ချိတ်ဆက်ထားတာ မဟုတ်ရင် ဘယ် App ကိုမှ Download and Install မလုပ်ဖို့ အရေးကြီးပါတယ်။ အပေါ် က App တွေထဲက တစ်ခုခု သင့် ဖုန်းထဲမှာရှိနေတယ်ဆိုရင် ချက်ချင်းဖျက်ပစ်ဖို့ အရေးကြီးပါတယ်။

Safety Net ဆိုတာကတော့ အလွယ်‌‌ပြောရရင် Protection mechanism ထည့်သွင်းတည်ဆောက်ထားတာကို ဆိုလိုတာပါ။

Apple Pay, Paypal တို့လို Digital Wallet မျိုးကျတော့ ကြားခံ Custodian လို့ ခေါ် တဲ့ Apple, Bank တွေ ရှိတဲ့ အတွက် သူတို့ရဲ့ ထိန်းချုပ်မှု တစိတ်တပိုင်း (သို့မဟုတ်) အပြည့်အဝ ရှိတဲ့ အတွက် ငွေမှားလွှဲမိတာ တို့ ၊ မိမိ မသိလိုက်ပဲ ငွေလွှဲ ထားတာတို့ ဆိုရင် ပြန်လည်ရယူနိုင်တာမျိုးပေါ့။

Crypto Wallet တွေ မှာလဲ Centralize Exchange တွေ က ထုတ်ပေးထားတာမျိုးဆိုရင် Safety Net တချို့ တလေ ပါတဲ့ အတွက် လုံခြုံမှု အတိုင်းအတာ တခုထိ ရရှိနိုင်ပေမယ့် Decentralize Crypto Wallet App မျိုးဆိုရင်တော့ mnemonic phrase အခိုးခံရတာတို့ ၊ ပျောက်သွားတာ မေ့သွားရင်တော့ အဆုံးလို့သတ်မှတ်ရမှာပါပဲ။

Report မှာ နိဂုံးချုပ်ထားတာကတော့ 'ဒီလှုပ်ရှားမှုဟာ အလျင်အမြန်တိုးပွားနေတဲ့ Digital Wallet, Crypto Wallet App အသုံးပြုသူတွေကို ပစ်မှတ်ထားပြီး စနစ်တကျစီစဉ်ထားတဲ့ phishing operation ကို မီးမောင်းထိုးပြနေပါတယ်။ 

Google Play Store ကနေ Fake Android App (၂၀) ကျော်ကို ဖြန့်ဝေခြင်းအားဖြင့် Attackerတွေဟာ PancakeSwap, SushiSwap, Raydium စတဲ့ Legit Wallet App တွေကို အတုယူပြီး အသုံးပြုသူတွေရဲ့ ဒစ်ဂျစ်တယ်ပိုင်ဆိုင်မှုတွေကို ဝင်ရောက်ဖို့အတွက် မရှိမဖြစ်လိုအပ်တဲ့ စကားလုံးအတွဲ (mnemonic phrases) တွေကို ခိုးယူနေကြပါတယ်။ 

ဒီလှုပ်ရှားမှုကို အထူးသဖြင့် အန္တရာယ်များစေတာကတော့ ယခင်က အန္တရာယ်မရှိခဲ့ဖူးတဲ့ (သို့မဟုတ်) လုံခြုံမှုမရှိတော့တဲ့ developer အကောင့်တွေအောက်မှာ ထားရှိတဲ့ Legit ဖြစ်ပုံပေါ်တယ်လို့ ထင်ရတဲ့ App တွေကို အသုံးပြုထားခြင်းအပြင်၊

Traditional Protection တွေ ရဲ့ Detection ကို ရှောင်ရှားနိုင်ဖို့ နဲ့ Attack Surface ကို ပိုကျယ်ကျယ်ပြန့်ပြန့် ရောက်စေဖို့  Webiste Domain (၅၀) ကျော်နဲ့ ချိတ်ဆက်ထားတဲ့ Phishing Infrastructure တွေပါ ပေါင်းစပ်ထားပါသေးတယ်တဲ့။

နောက်ဆုံး အနေနဲ့ Cyble က လူတွေကို စိစစ်ပြီးသား developer တွေဆီကနေပဲ App တွေကို Download and Install လုပ်ဖို့နဲ့ ဘာကိုမဆို Download and Install မလုပ်ခင် သုံးသပ်ချက်တွေကို ကြည့်ဖို့ အကြံပြုထားပါတယ်။ 

သူတို့က အသုံးပြုတွေအနေနဲ့ ကွန်ပျူတာ၊ လက်ပ်တော့ပ်နဲ့ ဖုန်းလိုမျိုး ပစ္စည်းတွေမှာ ယုံကြည်စိတ်ချရတဲ့ Antivirus, Internet Security Software တွေကို အသုံးပြုသင့်တယ်လို့လည်း အလေးအနက်ထား ပြောကြားထားပါတယ်။ 

Password တခုထက်ပို တဲ့ multi-factor authentication ကို အသုံးပြုဖို့ ကိုလဲ အကြံပြုထားပြီး လုံခြုံရေး ပိုမိုကောင်းမွန်ဖို့အတွက် တတ်နိုင်သမျှ Face, Fingerprint တို့လို biometric data တွေကို အသုံးပြုဖို့လည်း တိုက်တွန်းထားပါတယ်။

သင့်ဖုန်းရဲ့ လုံခြုံရေးအတွက် ဒီအချက်အလက်တွေက အထောက်အကူပြုမယ်လို့ မျှော်လင့်ပါတယ်။ 

ပျော်ရွှင်ပါစေဗျာ။

(Be knowledgeable, pass it on then)

The Security Artichoke Metaphor: Understanding Layered Defense in Cybersecurity

လက်ပတ်နာရီတို့ ၊ အိမ်က ရေခဲသေတ္တာတို့ ၊ Smart Bulb တို့၊ Smart TV/CCTV တို့က အစ အင်တာနက် က နေ လှမ်း ပြီး Control လုပ်လို့ရနေတဲ့ ဒီနေ့လို ခေတ်ကြီး မှာ ကျတော် တို့ လို Information Security Professional တွေ အတွက် အရင်က သုံးနေတဲ့ Security Onion Model ကို သုံးဖို့ သိပ်အဆင်မပြေ တော့ ပါဘူး။

အဲဒီအတွက် System/ System Group တခုချင်းစီအတွက် Security Artichoke ဆိုတဲ့ Model ကိုသုံးဖို့ လုပ်လာကြရပါတယ်။

သို့ပေမယ့် Security Artichoke Model ဟာ လုံခြုံ တယ်၊ မလုံခြုံ ဘူးဆိုတဲ့ အဖွဲ့ နှစ်ဖွဲ့ ကွဲနေပြန်ပါရော။

ကျတော် က Security Artichoke Model ဟာ မလုံခြုံ ဘူး ဆိုတဲ့ အဖွဲ့ ဖက်ကနေ ဘာလို့ မလုံခြုံ တာလဲ ဆိုတာကို နည်းနည်း ရှင်းပြချင်ပါတယ်။

Security Onion မှာဆိုရင် System အားလုံး အတွက် layered security defense လို့ ခေါ် တဲ့ တလွှာချင်းစီကို လုံခြုံ ရေး အဆင့် ခံ ထားတဲ့ အတွက် Attacker တယောက်အနေနဲ့  Core Data/System ဆီကို ရောက်ဖို့ တဆင့်ချင်းစီကို ထိုးဖောက်ရမှာဖြစ်လို့ပါပဲ။

Security Artichoke မှာကျတော့ Core Data/System ဆီကို ရောက်ဖို့ အတွက် Attacker တယောက်က  လုံခြုံ ရေး တလွှာချင်းစီကိုထိုးဖောက်ဖို့ ကြိုးစားစရာမလိုပဲ။ Core Data/System ကို ရောက်နိုင်တဲ့ လုံခြံရေး အလွှာ တခုကို ချိုးဖျက်နိုင်တာနဲ့ ရသွားနိုင်တာဖြစ်နေလို့ပါ။

ဥပမာ အနေနဲ့  Corporate Infra ကို Access လုပ်နိုင်တဲ့ BYOD တခုခုရဲ့  IoT/Bluetooth Gadgets (Wireless Earbud/Smart Tracker လိုဟာမျိုး) ကို Exploit လုပ်နိုင်ရင်ကိုပဲ အဲ့ကနေ တဆင့် Lateral Movement လုပ်သွားပြီး Core Data/System ကို ရောက်နိုင်ဖို့ လွယ်လို့ပါ။

IoT gadgets တွေဟာ ဆိုရင် minimum hardware ပေါ် မှာ သူတို့ Firmware ကို Run နိုင်အောင် လုပ်ထားရလို့ လုံခြုံ ရေး ပိုင်း နဲ့ ပတ်သတ်တာမှန်သမျှ အားလုံးနီးပါး ထည့်သွင်းထားလေ့ မရှိတဲ့ အပြင် Manufacture/Vendor တွေက လဲ Security Fix Update တွေ မထုတ်ကြတာများတဲ့ အတွက် အလွယ်တကူ ချိုးဖောက်နိုင်ကြပါတယ်။

Security Artichoke ဟာ လုံခြုံတယ်ဆိုတဲ့ အဖွဲ့က ပြောတာကတော့ ဒီလိုပါ။

အပေါ် မှာ ဥပမာပြောထားတဲ့ ပြဿနာမျိုးက Security Artichoke ရဲ့ အားနည်းချက်ကြောင့် မဟုတ်ပဲ Implementation လုပ်တဲ့သူတွေ ရဲ့ အားနည်းချက်ကြောင့် ပါတဲ့။

အဲ့လို ပြဿနာမျိုးကို မဖြစ်အောင် လုပ်ရမယ့် နည်းလမ်းတွေ အများကြီး ရှိတဲ့ အထဲက ၃ မျိုးလောက် ကျတော် ပြန်လည် ဝေမျှချင်ပါတယ်။

၁) Zero Trust

 Corporate Infra ကို ချိတ်ဆက်မဲ့  ဘယ် အလွှာကပဲ ဖြစ်ဖြစ် No Trust လုပ်ရမှာ ဖြစ်ပြီး Authentication, authorization နဲ့ accounting ကို လုပ်ကိုလုပ်ရမှာပါတဲ့။

၂) Air-Gapping

Core Data/System ရှိတဲ့ အလွှာကို Physically Isolated လုပ်ထားရမှာဖြစ်ပြီး၊ လိုအပ်လို့ Access လုပ်မယ်ဆိုရင်တောင် အဆင့်ဆင့်သော ခွင့်ပြုမိန့် တွေ ရယူဖို့ လိုတဲ့ စနစ်တခု ရှိနေရပါမယ်တဲ့။

၃) Chaos Engineering

ဒါကတော့ Secured Layer တိုင်းဟာ သူတို့ လုပ်သင့်တဲ့ အလုပ်ကို မျှော်လင့်ထားသလို တကယ်လုပ်သလားဆိုတာကို လက်တွေ့ စမ်းသပ်ကြည့်ခြင်းပါတဲ့။

ဥပမာ အနေနဲ့ ပြောရမယ်ဆိုရင် အနည်းဆုံး အပေါ် ကပြထားတဲ့ Zero Trust System တခုကို Disable လုပ်လိုက်ပြီး  Core Data/System ကို Red Team/Penetration Tester က ထိုးဖောက်နိုင်လား ဆိုတာကို စမ်းကြည့်တာမျိုးပါ။

Onion ကတော့ ကြက်သွန်နီဥ ဆိုတော့ ကြက်သွန်ဖက် အလွှာလေးတွေ ကို ပြောတာမှန်း သိသာပေမယ့် Artichoke ဆိုတာကို ကျတော်လဲ မြန်မာလို မသိလို့ မရေး ပြတော့ဘူး။ ‌

ဂေါ်ဖီ ထုပ်လိုလို၊ ငှက်ပျောဖူးလိုလို ပဲ။ ဒါနဲ့ Artichoke ဆိုတာ မျက်လုံးထဲ မြင်အောင် ပုံလေးပါ ပြထားပါတယ်။

မြန်မာနှစ်သစ်မှာ အားလုံးပဲ ဘေးဘယာဝေးကွာပြီး ကိုယ်စိတ်နှစ်လုံး ရွှင်ပြုံး ကျန်းမာကြပါစေဗျာ။

ပျှော်ရွှင်ပါစေ။

(Be knowledgeable, pass it on then)

Network Challenges and Requirements for AI Workloads for Network Engineers

 ယနေ့ ခေတ် မှာ ကျတော်တို့ တွေ သုံးနေတဲ့ Mobile Application/Web Application တွေ ဟာ Real-Time  အလုပ်လုပ်နေ တာ က အများဆုံးဖြစ်ပါတယ်။

ဥပမာ Facebook/Gmail လို App တောင် မှ Application ကို ကိုယ် ဘယ် Device ပေါ် မှာသုံးနေလဲ။ ဘယ် IP ကနေ သုံးနေလဲ။ ဘယ်အချိန်မှာ သုံးနေလဲ စတာတွေ ကို အမြဲ check and detect လုပ်နေပြီး တကယ့် Account ပိုင်ရှင် အစစ်က သုံးနေတာလား၊ တခြား တယောက်ယောက်က သုံးနေတာလားဆိုတာကို ဆုံးဖြတ်ဖို့ (Inferencing လုပ်တယ်လို့ ခေါ် ပါတယ်) နောက်ကွယ်ကနေ စောင့်ကြည့် နေတာမျိုးပေါ့။

ခုခေတ် မှာ အဲ့လိုလုပ်နေနိုင်ဖို့ အတွက် AI/ML infrastructure တွေ ကို သုံး နေ တာပါ။

ဒီလို AI/ML infrastructure တွေ အတွက် လိုအပ်တာက 

Backend မှာဆိုရင် Up-to-date dataset တွေ နဲ့ Training လုပ်ဖို့အတွက် AI/ML Server Nodes တွေ၊

 Train လို့ရလာတဲ့ Model နဲ့ Inferencing Engine တွေ Deploy လုပ်ဖို့ အတွက် Edge Device/User Device တွေပါ။

ဒါပေမယ့် Training နဲ့ Inferencing အတွက် လိုအပ်တဲ့ တကယ့် အ‌‌ရေးကြီး တာ တခုကတော့ Networking ပါပဲ။

အပေါ် က ဥပမာ ပြထား တဲ့ Real-Time Application လို မျိုး အတွက် အလုပ်လုပ်ပေး နေတဲ့ AI/ML Infrastructure တခုဟာ Training တွေ လုပ်ပေး နေတဲ့ AI Node Server တွေ အတွက် High-Bandwidth, Non-Blocking Lossless Network နဲ့ Congestion Management တွေ ဟာ မဖြစ်မနေ ကို လိုအပ်လာပါတယ်။

ဒါတင်ပဲလားဆိုတော့ Inferencing အတွက် လဲ Low Latency နဲ့ Low Jitter network connection ဟာ မဖြစ်မနေ လိုအပ်လာပါတော့တယ်။

AI/ML တွေ ဟာ GPU တွေ ပေါ် မှာ Run နေတာ ဖြစ်တဲ့ အပြင် low latency နဲ့ low jitter network connection ရအောင် လုပ်ဖို့ အတွက် CPU load ကို လျော့ ဖို့ လိုလာပါတယ်။

ဒီအခါ မှာ Remote Direct Memory Access over Converged Ethernet (RoCEv2) protocol ဆိုတာကို ကျတော် တို့ Network သမားတွေ ဟာ Quality of Service (QoS) နဲ့ တွဲသုံးရပါတော့ တယ်။

ဒါမှသာ AI/ML Infrastructure တခုရဲ့ လိုအပ်ချက်တွေ ဖြစ်တဲ့ 

High-Bandwidth

Non-blocking lossless network

congestion management

low latency

low jitter ဆိုတာတွေ ကို ရလာနိုင်မှာဖြစ်ပါတယ်။

အခုရေးပြထားတာ‌တွေ ဟာ Cisco U က နေ ပေးထားတဲ့ AI Solutions on Cisco Infrastructure Essentials | DCAIE ကို တက်ပြီး တကယ့်ကို အပေါ် ယံ လောက်သာ ရေးထားတာပါ။

 AI/ML Infrastructure တွေ အတွက် ကျတော် တို့ Network သမားတွေ တကယ်လေ့လာရမယ့် အပိုင်းတွေ အများကြီး ရှိလာပါတော့တယ်။

နောက်များ အချိန်ရလာနိုင်ရင် အသေးစိတ်ရေးနိုင်မယ်လို့ မျှော်လင့်ပါတယ်။

ကျေးဇူးတင်ပါတယ်။

ပျော်ရွှင်ပါစေဗျာ။

(Be knowledgeable, pass it on then)

Things to note for Typosquatting Domain Attack

 ဇူလိုင်လ တုန်းက တကမ္ဘာလုံး အတိုင်းအတာနဲ့ ထိခိုက်စေခဲ့ တဲ့ CrowdStrike ရဲ့ IT Incident ကို တော်တော်များများ မှတ်မိကြမယ် ထင်ပါတယ်။

CrowdStrike ဟာ Security Agent Incident တခုကိုပဲ ရင်ဆိုင်ဖြေရှင်းခဲ့ရတာတော့ မဟုတ်ပါဘူး။

သူ့ ရဲ့ Security Agent ကြောင့် ဖြစ်တဲ့ Incident အပြင် Typosquatting Domains တွေ ကြောင့် ဖြစ်လာတဲ့ ကိစ္စ တွေ ကို ပါ လိုက်ရှင်းရတာပါ။

Typosquatting Domains ဆိုတာကတော့ ဆင်တူယိုးမှား Domain တွေ လုပ်၊ Company ရဲ့ Logo နဲ့ တခြား အချက်အလက်တွေ ကို ကူးတင်ထားပြီး User တွေ Browser website မှားရိုက်လိုက်လို့ ရောက်လာတာကနေ အကျိုးအမြတ် ရအောင် လုပ်ထားတာပါ။

Information Security သမားတွေ အတွက် ခေါင်း ခဲ စေတဲ့ ကိစ္စ တွေ ထဲမှာ ဒါလဲ ထိပ်ဆုံးကပါပါတယ်။ ဘာလို့လဲ ဆိုတော့ Company Brand Reputation ကိုပါထိခိုက် ဆုံးရှုံးမှုတွေ ရှိနိုင်လို့ပါ။

CrowdStrike က ဖြစ် သွားတဲ့ Typosquatting Domains တွေ မှာတော့ အောက်က အချက်တွေ နဲ့ User တွေ ကို ပစ်မှတ်ထားတယ်လို့ Akami က လုပ်တဲ့ စစ်တမ်းက နေ သိရပါတယ်။

- False support claims: Company က တကယ်မပေးတဲ့ Service တွေ ပေးသလိုနဲ့ Login credential တွေ ရဖို့ ကြိုးစားတာ

- Urgency tactics: System တွေ Down နေ တာကို အခွင့်ကောင်းယူပြီး အခုမှ မလုပ်ရင် မရဘူးဆိုတာမျိုး နဲ့ တခုခု (App သွင်းခိုင်းတာ၊ လင့်တွေနှိပ်ခိုင်းတာ စသည်ဖြင့်) လုပ်ခိုင်းတာ 

- Malicious ZIP files: Bug fix ပါတယ်ပြောပြီး Malware ပါတဲ့ ZIP ဖိုင်ကို Download လုပ်ပြီး ဖွင့်ခိုင်းတာ

- Phishing Email : Social media ပေါ် မှာ တက်လာတဲ့ အချက်အလက်ကို ကြည့် ပြီး Targeted Phishing Email တွေ ပို့ပြီး ဖန်တီးထားတဲ့ Fake Website တွေ ဆီရောက်အောင်လုပ်တာ။ Credentials တွေ ရယူတာမျိုးတွေ လုပ်ပါတယ်။ 

အထက်ပါ နည်းလမ်းများနဲ့  Incident တခုကို အကြောင်းပြုပြီး Panic Users များဆီက နေ System access, Credentials တွေ ရဖို့ ကြိုးစားကြပါတယ်။

ဒီတော့ အပေါ် က လို ဖြစ်ရပ်မျိုးကို ကိုယ့်ဆီမှာ လဲ ဖြစ်လာတဲ့ အခါ ဘယ်လိုဖြေရှင်းသင့်လဲ ဆိုရင် 

၁) User ကို  Email လက်ခံရာမှာ Sender နဲ့ Email content ကို အမြဲ စစ်ဆေးဖို့ Information Security Awareness သင်တန်းပေးပါ။

၂) Incident တကယ်ဖြစ် လာရင် IT Team ကို ပဲ ဆက်သွယ်ဖို့ နဲ့ တကယ့်တရားဝင် Website, Social Media Page တွေ ကို သိနေစေ ဖို့ သတိထားတတ်ဖို့ Training ပေးပါ။

၃) နောက် တခု ကတော့ Company Data တွေ သုံးပြီး တုပထားတဲ့ Typosquatting Domains တွေ ကို  Netcraft တို့ Bolster တို့လို Automatic Domain Takedown Service Tool တွေ နဲ့ အမြဲ Scanပြီး  ဖြုတ်ချနိုင်ဖို့ပါပဲ။

အားလုံးပဲ Typosquatting ကနေ ဖြစ်လာမယ့် Cyber Security Incident တွေ ကို ကျော်လွှားနိုင်ကြပါစေ။ 

ပျော်ရွှင်ပါစေဗျာ။

(Be knowledgeable, pass it on then)

Some recommendation about password from NIST SP 800-63B

 Harvard က ပေးတဲ့ သင်ခန်းစာ တခုကြည့်ရင်း သင်ခန်းစာထဲက ညွှန်းတဲ့  

NIST Special Publication 800-63B ကို ဖတ်ကြည့်တော့ အဲ့ထဲက Digital Identity Guidelines: Authentication and Lifecycle Management မှာ အောက်က Recommendation နှစ်ခုပါတယ်။

Memorized secret verifiers SHALL NOT permit the subscriber to store a "hint" that is accessible to an unauthenticated claimant. 

Verifiers SHALL NOT prompt subscribers to use specific types of information (e.g., "What was the name of your first pet?") when choosing memorized secrets.

ခုလက်ရှိထိ Company တော်တော်များများ က သူတို့ရဲ့  Website, Application တွေမှာ အပေါ် က ၂ ခု ကို မလိုက်နာကြသေးဘူး။ 

Social Media, AI ခေတ်မှာ မင်း ရဲ့ ပထမဆုံး Pet က ဘာလဲ၊ မင်း ပထမဆုံး စီးခဲ့တဲ့ ကားက ဘာ မော်ဒယ်လဲ ဆိုတာတွေက  သိဖို့မှ မခက်တော့တာနော်။ 

ကိုယ်မဟုတ်တဲ့ တခြားသူက ကိုယ့်ရဲ့ Password ကို recovery ပြန် ယူဖို့ လွယ်သွားတာပေါ့။ 

Verifiers SHOULD NOT require memorized secrets to be changed arbitrarily (e.g., periodically).

ခုအချိန်ထိ Corporate တွေ ရဲ့  Information Security Policy တွေ ထဲက Password Policy တွေမှာ Password ကို ရက် (၃၀)/ရက် (၄၅)/ ရက် (၉၀) တိုင်း ပြောင်းခိုင်းနေတာကြီးက အမြဲတွေ့ နေကြပါ။

Account Password တခု compromise ဖြစ် သွားတဲ့အချိန် (သို့မဟုတ်) လက်ရှိသုံးနေတဲ့ Account Password တခုခုကို Breach ဖြစ်သွားတဲ့နေရာက နေ Threat Intel က သိတဲ့အချိန်မျိုးမှ သာ Password ကို ပြောင်းခိုင်းသင့်ပါတယ်တဲ့။

နောက်ဆို Password Policy ကို Review လုပ်ပေးပါ ပြောရင် ဒါကြီး ကိုင်ပြီး ပြန်ငြင်းကပေါ့ ။ 

အဲ့ဒါကြောင့် ပြောတာ သိပ္ပံပညာရပ်က အမြဲ မမှန်ဘူး။ အရင်က တွေ့ ခဲ့တဲ့ သီအိုရီ က အခု ကျ မှားရင် မှားနေ တတ်တာမျိုးလေ။ 

သူငယ်ချင်းတို့ စာတွေ အရမ်းလုပ်မနေကြနဲ့ တော့ ...

ခုလို အဘိဓမ္မာအခါတော် နေ့ မှာ အမြဲမှန်တဲ့ အဝိဇ္ဇာ။ တဏှာ၊ နာမ် နဲ့ ရုပ်၊ သစ္စာလေးပါး တရားတွေ တာ သိအောင် အားထုတ်ကြတော့။ 😁

ပျော်ရွှင်ပါစေဗျာ။

(Be knowledgeable, pass it on then)

What is Domain Takedown Service?

Facebook, Instagram, Twitter/X စတဲ့ Social Media Platform မှာပဲ ဖြစ်ဖြစ် သတင်းမီဒီယာ Website တွေ မှာပဲ ဖြစ်ဖြစ် တခါတလေ ပို့စ် တွေ တက်လာပြီး ပြန် ပျောက်သွားတာမျိုး၊ ကိုယ်တိုင် Social Media Page ရှိတဲ့ သူတွေ ဆို Post ပျက်သွားတာမျိုး ကြုံ ဖူးကြမှာပါ။

အဲ့ဒါမျိုး ဟာ တခုက Platform ရဲ့  ပေါ်လစီနဲ့ ငြိ လို့ ၊ တခုကတော့ ကိုယ်တင်လိုက်တဲ့ Content ဟာ လူတယောက် သို့မဟုတ် အဖွဲ့ အစည်းတခုရဲ့  မူပိုင်ပစ္စည်း ဖြစ်နေတဲ့ အခါ မျိုးမှာ ဖြုတ်ချခံရတာပါ။

အခု ကျတော် ပြောချင်တဲ့ အကြောင်း အရာက ဒုတိယတခု ဖြစ်တဲ့ အဖွဲ့ အစည်းတွေ ရဲ့ မူပိုင်ပစ္စည်းကို ခွင့်ပြုချက်မရထားပဲ တရားမဝင်ခိုးယူ အသုံးပြု နေမှုကို ဘယ်လို နည်းပညာတွေ နဲ့ တားဆီးလဲ ဆိုတာပါပဲ။

"Building a brand may take 10 years, but it can be brought down within 5 minutes" ဆိုတဲ့ စကားကို ကမ္ဘာကျော် သူဌေးကြီး Warren Buffett က ပြောဖူးတယ်လို့ မှတ်ဖူးတာပဲ။ 

Digital အင်တာနက် ခေတ်မှာ Logo,  Photo, Software, Video တွေ ကို မူရင်း ဖန်တီးထားသူ၊ ပိုင်ဆိုင်ထားသူတွေ ရဲ့ ခွင့်ပြု ချက် မရယူပဲ အလွယ်တကူ ကူးယူပြီး အသုံးပြု ကြပါတယ်။

ဒီအခါမှာ မူရင်း ဖန်တီးသူ၊ ပိုင်ဆိုင်ထားသူ တွေ ဟာ သူတို့ Customer Trust ကျဆင်းခြင်း ၊ ရသင့်တဲ့ အကျိုးအမြတ် များ ဆုံးရှံးခြင်း၊ Reputation ကျဆင်းခြင်း  စတဲ့ နစ်နာမှုတွေ တသီတတန်းကြီး ခံစားရပါတယ်။

ဒါမျိုး အလွဲသုံးစားလုပ်မှု၊ တရားမဝင်ခိုးယူသုံးစွဲမှု တွေ ကို ကာကွယ်တားဆီးဖို့ ဆိုရင် AI ခေတ်မှာ Automatic Domain Takedown Service ဆိုတာမျိုးတွေ ရှိပါတယ်။

အဲ့ဒီ  Service က ဘာတွေ လုပ်ပေးလဲ ဆိုတော့ 

1)  Monitoring and Detection

အဆင့်မြင့်  Algorithms နဲ့ Automatic Web Crawler တွေ၊ မူပိုင် ပစ္စည်း တွေ နဲ့ သင်ကြားထားတဲ့ Machine Learning တွေ ၊ Real-time monitoring တွေ သုံးပြီး အင်တာနက်ကို စဉ်ဆက်မပြတ် scan လုပ်ပါတယ်။

2)  Evidence Accumulation

Trained Machine Learning နဲ့ Train ထားတဲ့ AI ကနေ ပြီးတော့ တရားမဝင် ခိုးယူ အသုံးပြု ထားတဲ့ Content တွေ ကို တွေ့ တာနဲ့ Screenshot, Video Recording, Audio Recording, Content ရဲ့ URL အစရှိတာတွေ နဲ့ သက်သေ မှတ်တမ်းယူပါတယ်။

3)  Stakeholder Identification and Automated Engagement

ရယူထားတဲ့ သက်သေ မှတ်တမ်းများကို သက်ဆိုင်ရာ Stakeholder များကို တင်ပြ အ‌ကြောင်းကြား ခြင်း နဲ့ လိုအပ်သလို လုပ်ဆောင်ဖို့ အသိပေးခြင်း ကို လုပ်ပါတယ်။

Facebook မှာ တင်ထားတာဆို Facebook Team, Blog/Website ပေါ် မှာ တင်ထားတာဆို Hosting Provider, Domain Registrar တို့ကို အကြောင်းကြားပြီး Follow-up action လုပ်ခိုင်းတာပါ။

4) Legal Interventions

တကယ်လို့ ဆိုင်ရာ Stakeholder တွေက follow-up action လုပ်ဖို့ ပျက်ကွက်ခဲ့တာနဲ့ တရားဥပဒေ ဆိုင်ရာ လုပ်ထုံး လုပ်နည်းတွေ နဲ့ ဆက်လက်လုပ်ဆောင် ခြင်း (DMCA (Digital Millennium Copyright Act) လိုမျိူး တွေ သုံးပြီး follow-up action လုပ်ဖို့ notice စာ ပို့တာမျိုး ) ကို လုပ်ပါတယ်။ 

5) Post-takedown Monitoring

ကိုယ့် ရဲ့ မူပိုင် ပစ္စည်း ကို တရားမဝင်အသုံးပြု နေခြင်း က နေ ဖြုတ်ချ နိုင်ခဲ့ ပြီး တဲ့ နောက်မှာ အလားတူ လုပ်ရပ်မျိုး ထပ် ကျူးလွန်ခြင်း မရှိအောင် ဆက်ပြီး စောင့်ကြည့် ခြင်းကို လုပ်ပါတယ်။

ဒီလို အလုပ်တွေ ကို အရင်ကဆို လူ့ စွမ်းအား အရင်းအမြစ် များစွာ၊ အချိန်များစွာ အသုံးပြု ပြီး မှ လုပ်လို့ရနိုင်တာပါ။

အခု AI ခေတ်မှာတော့ ဒါမျိုးတွေ ကို မိနစ်ပိုင်း နာရီပိုင်း အတွင် အလိုအလျောက် လုပ်ပေးနိုင်တဲ့ Services/Tool တွေ အမြောက်အမြား ရှိနေပါပြီ။

လေ့ လာ ထားမိ သလောက် ထဲက နာမည်ကျော်ကြား လူသုံးများတဲံ Automatic Domain Take Down Service တွေ ကတော့ 

1. ZeroFOX’s Domain Takedown Service

2.Cloudsek Takedown Service

3.Phishfort

4.Bolster Automated Takedown Service

5.Styx Takedown Service

6.SiteTakeDown Service

7. BrandShield

8. BrandVerity

9. Fortra PhishLabs

10. Recorded Future Brand Intelligence

11. Red Points

တို့ပဲ ဖြစ်ပါတယ်။

ကဲ...သင်ဟာ Cybersecurity Professional တယောက်လဲ ဖြစ်တယ်။ သင့် Organization ရဲ့  Copyrighted Materials, Trade Secret အစရှိတဲ့ မူပိုင်ပစ္စည်းတွေ၊  Brand Impersonation လို Reputation အတွက် အရေးကြီးတာတွေ ကို ကာကွယ်ဖို့ လဲ တာဝန်ရှိနေပြီ ဆိုရင် သင်ရော ဘယ်လို Automatic Domain Takedown Service မျိုးကို ရွေးချယ်သုံးမလဲ။ သုံးနေပြီလဲ။

စျေးကတော့ မသေးဘူးဗျို့ ။

ပျော်ရွှင်ပါစေဗျာ။

(Be knowledgeable, pass it on then)

Blue-Green and Canary Deployment

Continuous Integration, Continuous Development Cloud Computing , DevOps လောကမှာတော့ Blue-Green Deployment နဲ့ Canary  Deployment ဆိုတာ မသိမဖြစ်တွေ ပါပဲ။

လူတိုင်း ကွန်ပျူတာကို လက်ပတ်နာရီလို၊ ဖုန်းလို သယ်သွားနေတဲ့ Digital ခေတ်မှာ အသုံးပြု သူတွေ အတွက် No/Low downtime application တွေ ဟာ လိုအပ်လာပါတယ်။

ဒီအတွက် Application တွေ Host လုပ်တဲ့ Infrastructure သမားတွေ ဟာလဲ Application Developer များ အတွက် No/Low downtime Environment တွေ ရှိနေဖို့ လုပ်ဆောင်ထား‌ပေးဖို့ လိုအပ်လာပါတယ်။

ဒီလို လုပ်ထားပေးဖို့ ဆိုရင် အပေါ် က Blue-Green Deployment နဲ့ Canary Deployment ဆိုတာကို ပြည့်ပြည့် ဝဝ နားလည်ဖို့ လဲ လိုပါတယ်။

Blue-Green Deployment တခု လုပ်ဖို့ ဆိုရင် 

Blue နဲ့ Green environment တထပ်တည်း တူတဲ့ Infrastructure ရှိနေရမှာ ဖြစ်ပြီး၊

Developer က Green Environment မှာ New Version release လုပ်ပြီး စမ်း၊

Blue Environment က Production Live Traffic ကို Handle လုပ်။

New version release လုပ်လို့ ရပြီ ဆိုတဲ့ အချိန်မှာ Blue Environment က Traffic ကို Green Environment ကို Transfer လုပ်ပေးခြင်း ဖြင့် no/low dowmtime application တခု ရနိုင်ပါတယ်။

အလားတူ Blue မှာ စမ်း Green မှာ release လုပ်နဲ့ တလှည့်စီ သွားနေတာကို support လုပ်နေရမှာ ပါ။

ဒါကို ပဲ Blue-Green Deployment လို့ ခေါ် တာပါပဲ။

ကျတော်တို့ Facebook သုံးရင်း နဲ့ တချို့  Feature အသစ်တွေ ကိုယ့်ဆီမှာ ပေါ် နေပြီး ကိုယ့် သူငယ်ချင်းဆီမှာ ရ မနေတာမျိုး၊ သူများတွေ ဆီမှာ Feature အသစ်တွေ ရနေပြီး ကိုယ့်မှာ ရ မနေ တာမျိုး ကြုံဖူးကြမှာ ပါ။

အဲ့ဒီလို ဖြစ်အောင် လုပ်ထား တာကို Feature Toggle/ Feature Flag လို့ ခေါ် ပြီး၊ လူတိုင်းမှာ ရမနေပဲ Random user တွေ မှာပဲ ရနေအောင် လုပ်ထားတာကိုတော့ Canary Development လို့ ခေါ် ပါတယ်။

Application Developer တွေ အနေနဲ့  တကယ့် Production မှာ deploy လုပ်စရာ မလိုပဲ

ဒီ Feature Flag ကို on/off လုပ်ပေး နိုင်ခြင်း ဖြင့် application နဲ့ user တွေ ရဲ့  Behaviour ကို အမှားနည်းနည်းနဲ့ အချိန်မကုန်ပဲ လေ့ လာ ပြု ပြင် ထိန်းသိမ်းနိုင်ပါတယ်။

ဒီတော့ အပေါ် က Deployment ၂ မျိုးမှာ 

Blue-Green Deployment ကတော့ Live Traffic ကို Environment ၂ ခု ကြားမှာ 100% Switch လုပ်ပေးတာနဲ့ ၊

Canary Deployment မှာကတော့ Random user အနည်းငယ်အတွက် Traffic ကို ခွဲထုတ်ပေးတာ ကွာခြားသွားတာပါ။

တကယ်လို့ သင်ဟာ CICD ကို ရှယ်ပလန်နဲ့ သုံးနေတဲ့ အလုပ်တခုမှာ DevOps သမား၊ Infra သမားတယောက် ဖြစ်နေမယ်ဆိုရင် ဒီ နည်းလမ်းတွေ ကို ရင်းနှီးနေရမှာ ဖြစ်ပြီး လိုအပ်တဲ့ Infra ကို သေချာ support ပေး နိုင်ရမှာပဲဖြစ်ပါတယ်။

AWS မှာ ဆိုရင် Elastic Beanstalk , Azure မှာဆိုရင် App Service, Google မှာ ဆိုရင် App Engine တွေ နဲ့ ဒီနည်း ၂ မျိုးကို စမ်းကြည့် လို့ရပါတယ်။

အားလုံးပဲ မြန်မာနှစ်သစ်မှာ အသိပညာ အသစ်တွေ နဲ့ ကျန်းမာ ချမ်းသာ ကြပါစေ။ 

ပျော်ရွှင်ပါစေဗျာ။

(Be knowledgeable, pass it on then)

SASE Architecture and Cisco

 ပြီးခဲ့တဲ့ လပိုင်းလောက်က CCIE renewal လုပ်ဖို့ အစီအစဉ်ဆွဲရင်းက ကိုယ့် နံပါတ်လေးလဲ သက်တမ်းတိုးပြီး သားဖြစ် Cisco ရဲ့ Core Technology တွေ ထဲက Cisco Security Core Technologies တွေ ကို လေ့လာပြီးသားလဲ ဖြစ်  အောင် 350-701 Exam ဖြေ ဖို့ အတွက် အောက်ပါ အကြောင်းအရာတွေ ကို လေ့လာဖြစ်တယ် ဆိုပါတော့။

Cisco ASA Firewall

Cisco Firepower Next-Generation Firewall (NGFW)

Cisco SSL VPN (Cisco AnyConnect)

Cisco Identity Services Engine (ISE)

Cisco Advanced Malware Protection (AMP)

Cisco Umbrella for DNS security

Cisco Email Security Appliance (ESA)

Cisco Web Security Appliance (WSA)

Cisco Stealthwatch (SIEM)

Cisco Talos Threat Intelligence

Cisco SecureX Security Platform

Cisco Duo (Multi-Factor Authentication)

Cisco Adaptive Security Appliance (ASA) Software

Cisco Next-Generation Intrusion Prevention System (NGIPS)

Cisco Cloudlock (Cloud Security)

အပေါ် က အကြောင်းတွေ လေ့လာရင်းကနေ ခေါင်း ထဲ အတွေး နယ်ချဲ့ မိတာက Cisco ဟာ တခြား Vendor တွေ နဲ့ မတူပဲ ဘာလို့ များ အကုန်လုံး ကို စွတ်လုပ်နေလဲ ပေါ့။ 

နောက် အရင်က လေ့ လာ ဖူးတဲ့ အောက်က ခေါင်းစဉ်တွေ ကို ထည့်ပေါင်းကြည့် လိုက်တော့မှ  SASE ဆိုတာခေါင်းထဲ ထင်းကနဲ ပေါ် လာတော့ တယ်။

Cisco DNA

Cisco ISE

Cisco SD-WAN

Cisco ဟာ Secure Access Service Edge (SASE) လမ်းကြောင်းကို သွားနေတာ အတော် ခရီးပေါက် နေပြီဆိုတာပါပဲ။

ဘာလို့လဲ ဆိုတော့ SASE တခု ရှိရမယ့် 

Security

Flexibility

Speed

Cost-Effective

Better Performance

Simplicity

ဆိုတဲ့ အချက်တွေ အကုန်လုံးကို Cisco က စုစည်းလာတာ အပေါ် မှာ list ထုတ်ထားတဲ့ စာရင်းပါပဲ။

ကိုယ့်တယောက်ထဲ အမြင် အရ ဆိုရင် Cisco ရဲ့  Product တွေ ဟာ  Born-in Cloud vendor တွေ ရဲ့  Product တွေ လို Cloud ပေါ် မှာ ပေါ့ ပေါ့ ပါးပါး run နိုင်တဲ့ တနေ့ Cisco ဟာ အရင်က Networking လောက မှာ ထောင်ထောင် ထောင်ထောင် လုပ်နိုင်ခဲ့သလို Cloud ပေါ် မှာလဲ ဖြစ်လာနိုင်အုံးမယ်ထင်တာပါပဲ။

ပျော်ရွှင်ပါစေဗျာ။

(Be knowledgeable, pass it on then)

Crypto Shredding in Cloud Computing Data Security

ရုပ်ရှင်တွေထဲမှာ  SIM card, Microchip, Memory Chip စတာတွေ ကို Microwave Oven ထဲထည့်ပြီး ဖျက်ဆီးပစ်တာတို့ ၊

Hard Disk လို Storage device တွေ ကို Drilling Machine နဲ့ ထိုးဖောက်ပြီး ဖျက်ဆီးတာတို့၊ Crashing machine ထဲ ထည့်ပြီး တစစီ ချေမွ ပစ်တာတို့ ကို မြင်ဖူး ကြမှာပါ။

အဲ့ဒါမျိုး ကို Data Destruction လုပ်တယ်လို့ ခေါ် ပါတယ်။

Electric Value အနေနဲ့ Storage Device တွေ ထဲမှာ ကျန်နေတဲ့ Data တွေ ကို သံလိုက်လှိုင်း သုံးပြီး ဖျက်ဆီးတာမျိုးကို ကျတော့  Degaussing လုပ်တယ်လို့ ခေါ် ပါတယ်။

Paper ပေါ် က Data မျိုးကျတော့ မီးရှို့ တာတို့၊ Shredder သုံးပြီး ဖျက်ဆီးတာတို့ လုပ်ကြတာပေါ့။

ဒီ အပေါ် က လုပ်ငန်းစဉ်တွေ က On-Premise Infrastructure တွေ မှာ Data Security Policy အရ လုပ်ရတဲ့ လုပ်ငန်းစဉ် တွေ ပါ။  Data တွေ ကို Encryption လုပ်ထားပြီး သား ကို‌တောင် Physically ဖျက်ဆီး ပစ်ရပါတယ်။

Cloud Computing ခေတ်ရောက်လာတော့ Data Dispersion ဆိုတာ ကြီး ကြောင့် Data Security Policy ကို အမှားအယွင်းမရှိ လိုက်နာဖို့ ခက်ခဲလာပါတယ်။

Cloud Service Provider တွေ ဟာ သူတို့ ပေးထားတဲ့ Service Level Agreement ကြောင့် Cloud Service အသုံးပြု သူ တွေ ရဲ့ Data ကို Region ပေါင်းများစွာ မှာ Replicate လုပ်ထားကြ ရပါတယ်။

အဲ့လို Replicate လုပ်ထားတာကိုပဲ Data Dispersion လို့ ခေါ် တာပါ။

ဒီအခါမှာ အသုံးပြုတဲ့ အဖွဲ့အစည်းတွေ အနေနဲ့  Cloud Service Provider ရဲ့  Resource မှာ သိမ်းထားတဲ့ Data တွေ က ကမ္ဘာအရပ်ရပ်မှာ ရှိတဲ့ Data Center တွေ ဆီမှာ ရောက်နေပါတယ်။

ဒီအတွက် လက်ရှိ Cloud Service Provider ကို ဆက်လက်အသုံးမပြု ပဲ နောက် တခု ပြောင်း သုံး ဖို့ အခြေ အနေ ကြုံ လာတဲ့ အခါ Data Security Policy အရ Data တွေ ကျန်မနေ ခဲ့ အောင် Destruction လုပ်ဖို့ အခက်တွေ့ ကြ ရပါတယ်။ CSP တွေအနေနဲ့ Shared Storage Pool တွေ ကို Physical Destruction လုပ်မှာ မဟုတ် သလို၊ Dedicated Storage Pool တွေ ကို Destruction လုပ်တယ် မလုပ်ဖူး ဆိုတာကို ယုံကြည်ထားလို့ လဲ မရပြန်ပါဘူး။

ဒီအခါမှာ Crypto Shredding ဆိုတာဟာ အရေး ပါလာပါတယ်။

Crypto Shredding ကို Cryptographic Shredding လို့လဲ ခေါ် ကြပါသေးတယ်။

အလုပ်လုပ်ပုံကတော့ Storage device တခုမှာ ရှိနေတဲ့ Data ကို Encryption Algorithm တခု သုံးပြီး Encrypt လုပ်ပါတယ်။ Decrypt ပြန် လုပ် လို့ ရတဲ့ Key ကို နောက် တကြိမ် တခါ ထပ်ပြီး Encrypt လုပ်ပြီး ရလာတဲ့ Decryption Key ကို ဘယ်နေရာ မှာ မှ သိမ်းမထားပဲ ဖျက်ဆီးပစ်တာပါ။

နောက် တနည်းကတော့ ဒုတိယအကြိမ် Encrypt လုပ်တဲ့ အခါမှာ Decryption Key မပါပဲ Encrypt လုပ်လိုက်တာပါ။ ဒီနည်းကို သုံးတာ ကျတော့ အိုင်တီ သမား လက်ရှိ သက်တမ်းအထိ မတွေ့ ဖူးသေးပါဘူး။

ဒီလိုလုပ်ခြင်း အားဖြင့် Data Dispersion ကြောင့် ဖြစ် လာနိုင်တဲ့ Data Security Weakness တွေ ကို ကာကွယ်ပြီး သား ဖြစ်သွားပါတယ်။

Crypto Shredding ကို Cloud Computing ကို အသုံးပြု နေရတဲ့ အိုင်တီ သမားတွေ အနေ နဲ့  အတိအကျ လိုက်နာဖို့  အထူးလိုပါတယ်။

Cloud Resource တခု ဆောက်ပြီ ဆိုတာနဲ့  Encryption Algorithm သုံးပြီး Data in Transit/Motion, Data in use နဲ့ Data at rest တို့ကို Encrypt လုပ်ကို လုပ်ရမှာ ပဲ ဖြစ်ပါတယ်။

မလုပ်ထားရင်တော့ CSP ရဲ့  Data Dispersion ကြောင့်  နောင် တချိန်မှာ ဥရောပလို GDPR policy မျိုး က ကိုယ်ရော ကိုယ့်အလုပ်လုပ်နေတဲ့ အဖွဲ့ အစည်းရော ဒုက္ခ ပေး ဖို့ ဖြစ်လာမှာပါ။

ကျေးဇူးတင်ပါတယ်။

ပျော် ရွှင် ပါ စေ။

(Be knowledgeable, pass it on then)

Demystifying Service Principal (SP) and Managed Identity (MI)

Azure Cloud Architect တွေ ခေါင်း အစားရဆုံး ကတော့ ဘယ်အချိန်မှာ Service Principal  (SP) ကိုသုံးပြီး ဘယ်အချိန်မှာ Managed Identity (MI) ကို သုံးမလဲ ဆိုတာပါပဲ။

တကယ်က SP နဲ့  MI ရဲ့  နောက်ကွယ်က အလုပ်လုပ်ပုံ အမှန်တရားက အတူတူပါပဲ။

ကျတော် တို့ အရင် On-Premise AD တွေ သုံးတုန်းကဆိုရင် Application တွေ Service တွေ မှာ သုံးဖို့ Service Account ဆိုတာ Create လုပ်ပြီး သုံးကြ ရပါတယ်။

အဲဒီမှာ ပြဿနာက AD account တွေ ရဲ့ ထုံးစံ အရ Password Expiry Date ရှိနေတာပါပဲ။ Non-expired လုပ်ထားရင်လဲ Security အရ non-compliance ဖြစ်တဲ့ အတွက် ထားမရပါဘူး။

ဒီတော့ Password renew လုပ်ရတဲ့ Integrate လုပ်ထားတဲ့ Application, Service တွေ မှာ Password update လုပ်ရပါတယ်။

ဒီအခါမှာ Application, Network, System နဲ့ Infra သမားတို့ ထုံးစံ အတိုင်း ဘယ်နေရာ တွေမှာ Account ကို သုံးထားလဲ အကုန်မသိတဲ့ အခါ Production down တဲ့ impact မျိုးတွေ ကြုံ ရတာပါပဲ။

Azure Cloud မှာတော့ ဒီပြဿနာကို ဖြေရှင်း ဖို့ Service Principal (SP) နဲ့ Managed Identity (MI) ဆို တာ ရှိလာပါတယ်။

Service Prinicpal ဆိုတာက Create လုပ်လိုက်တာနဲ့ ID နဲ့ Credential ဆိုတာ ရလာပြီး၊ ရလာတဲ့ ID, Credential ကို Azure Keyvault လို Key, Secret Management Service တခုခုမှာ သိမ်းထားရပါတယ်။

ပြီး မှ Service Principal (SP) ကို Keyvault မှာ Role Base Access Control ပေးပြီး ပြန် သုံးရတာပါ။

SP ကို ဘယ်မှာ သုံးသင့်လဲ ဆိုတော့ AzureDevOps, Ansible, Terraform လို Automation Tools တွေ , Third Party Application, Enterprise Application တွေ မှာ Integrate လုပ်ပြီး Token Base Authenticaion တွေ နဲ့ သုံးသင့်ပါတယ်။

Managed Identity (MI) မှာ တော့ System-Assigned နဲ့ User-Assigned ဆိုပြီး နှစ်မျိုး ရှိပါတယ်။

System-Assigned ဆိုတာကတော့ Resource တခုမှာ ID တခု Assigned လုပ်ထားတာ ဖြစ်ပြီး Resource မရှိတော့ တာနဲ့ ID လဲ မရှိတော့ပါဘူး။

User-Assigned ကတော့ Azure AD မှာ Create လုပ်ပြီး Resource တွေ မှာ Assign ပြန်လုပ်ပြီး သုံးရတာပါ။

MI ရဲ့ ထူးခြား ချက်က Credential ကို မသိရတာပါပဲ။ ဒါကြောင့် ပဲ သူ့ အတွက် Credential ကို Azure Keyvault လို Secret Management Service တခုခုမှာ သွားသိမ်းစရာ မလိုတော့ပါဘူး။

သူကတော့ Azure Resource တွေ နဲ့ Link လုပ်ပြီး သုံးရတဲ့ အမျိုးအစားပါ။

ဥပမာ Azure File Share service ကို သုံးမယ့် Server VM တွေ အတွက် User-Assigned Storage Account Access MI တခု Create လုပ်ပြီး Server VM အားလုံးမှာ assign လုပ်တာမျိုးပေါ့။ 

အနှစ်ချုပ် ရမယ်ဆိုရင် ...

Service Prinicipal ကို Applications, Third Party Tools, Automation Tools တွေမှာ Integrate လုပ်ပြီး သုံးရမှာ ဖြစ်ပါတယ်။

သူ့ ကို သုံးမယ်ဆိုရင် Credential အတွက် Secret Key Management Service တခုခုလိုအပ်ပြီး၊ အနည်းငယ် ရှုပ်ထွေး ပြီး ပိုများ တဲ့ RBAC အဆင့်တွေ ကို အသုံးပြု ဖို့ လိုအပ်ပါတယ်။

Managed Identity ကို တော့ Azure Resource တွေ နဲ့ Link လုပ်ပြီး သုံးရမှာ ဖြစ်ပါတယ်။

သူ့ကို သုံးမယ်ဆိုရင်တော့ User-Assigned MI က‌တော့ Recommend ဖြစ်ပေမယ့် ကိုယ့် Architecture ပေါ် မူတည်ပြီး System-Assigned MI ကို လဲ သုံးသင့်ရင် သုံးရမှာပဲ ဖြစ်ပါတယ်။ System-Assigned ရဲ့ Life Cycle ကတော့ Resource ရဲ့ Life Cycle နဲ့ အတူတူပဲ ရှိတာကိုတော့ သတိချပ်ဖို့လိုပါတယ်။

ဒီလောက်ဆို SP နဲ့ MI အကြောင်း တီးမိခေါက်မိလောက်ပြီ ထင်ပါတယ်။

ကျေးဇူးတင်ပါတယ်။

ပျော်ရွှင်ပါစေ။

(Be knowledgeable, pass it on then)