ICT for Myanmar

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

noreply@blogger.com (Zaw Htet) — Thu, 26 Feb 2026 13:14:00 +0000

ယနေ့ခေတ်သုံး 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?

noreply@blogger.com (Zaw Htet) — Thu, 26 Feb 2026 13:10:00 +0000

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

noreply@blogger.com (Zaw Htet) — Sun, 28 Dec 2025 15:00:00 +0000

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

noreply@blogger.com (Zaw Htet) — Mon, 11 Aug 2025 04:40:00 +0000

အမေရိကန် သမ္မတ တို့၊ အီလွန်မက်စ် တို့ရဲ့ မျက်နှာနဲ့ တောင် လိမ်လာနေတဲ့ 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

noreply@blogger.com (Zaw Htet) — Fri, 13 Jun 2025 06:34:00 +0000

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

noreply@blogger.com (Zaw Htet) — Fri, 13 Jun 2025 06:32:00 +0000

လက်ပတ်နာရီတို့ ၊ အိမ်က ရေခဲသေတ္တာတို့ ၊ 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

noreply@blogger.com (Zaw Htet) — Sun, 09 Mar 2025 14:03:00 +0000

ယနေ့ ခေတ် မှာ ကျတော်တို့ တွေ သုံးနေတဲ့ 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

noreply@blogger.com (Mr.blogger) — Wed, 04 Dec 2024 09:27:00 +0000

ဇူလိုင်လ တုန်းက တကမ္ဘာလုံး အတိုင်းအတာနဲ့ ထိခိုက်စေခဲ့ တဲ့ 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

noreply@blogger.com (Mr.blogger) — Thu, 17 Oct 2024 16:33:00 +0000

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?

noreply@blogger.com (Mr.blogger) — Thu, 06 Jun 2024 13:02:00 +0000

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

noreply@blogger.com (Mr.blogger) — Wed, 17 Apr 2024 06:11:00 +0000

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

noreply@blogger.com (Zaw Htet) — Tue, 18 Jul 2023 15:22:00 +0000

ပြီးခဲ့တဲ့ လပိုင်းလောက်က 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

noreply@blogger.com (Zaw Htet) — Thu, 23 Mar 2023 15:40:00 +0000

ရုပ်ရှင်တွေထဲမှာ 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)

noreply@blogger.com (Mr.blogger) — Sat, 18 Mar 2023 06:01:00 +0000

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)

Stalkerware not Spyware

noreply@blogger.com (Mr.blogger) — Sun, 25 Sep 2022 04:18:00 +0000

Stalkerware ဆိုတာ လူတယောက်ချင်းစီ က သူတို့ စောင့်ကြည့်ချင်တဲ့ သူတွေကို တိတ်တဆိတ် စောင့်ကြည့်ဖို့ သုံးတဲ့ Application တခုပဲ ဆိုပါတော့။

သူက ဘာတွေလုပ်လဲ ဆိုရင် ...

Mobile Phone, Tablet, Computer တွေကနေ တယောက်နဲ့ တယောက် ဆက်သွယ်မှု (Phone Call, Chat, Messaging) တွေ ကို စောင့်ကြည့်တာ။

လက်ရှိ ဘယ်နေရာ ရောက် နေလဲ နဲ့ အရင်နေ့တွေက ဘယ်တွေသွားခဲ့လဲ (GPS location data) ဆိုတာကို စောင့်ကြည့် အသိပေးတာ။

Device ထဲက File, Photo လို အချက်အလက် တခုခု ပြောင်းသွားတာနဲ့ Stalkerware ရဲ့ Main Server ဆီကို update data ပို့ပေးတာ။ (ဥပမာ။ Photo ထဲမှာ ဓာတ်ပုံ အသစ်တွေ ရောက်လာရင် Server ဆီကို ပို့ပြီး သိမ်းလိုက်တာမျိုး။)

နာမည်ကြီး Stalkerware App တွေ ထဲက “Cerberus” , “Reptillicus” ဆိုတဲ့ App နှစ်ခုဆိုရင် WhatsApp, Telegram, Text Message တွေကို တောင် ဝင်ဖတ်နိုင်တယ်တဲ့။ Photo, Video တွေကို လဲ ဝင်ကြည့်နိုင်တယ်တဲ့ဗျ။

Stalkerware App တွေကို ကိုယ့် Device ထဲကို သွင်းဖို့ဆိုရင် Physical access ရှိမှ သွင်းလို့ရမှာ ဖြစ်ပြီး။ သွင်းယူမယ့်သူက ရင်းနှီးတဲ့သူလဲ ဖြစ်နိုင်သလို၊ မိမိကိုယ်တိုင်လဲ ဖြစ်နိုင်နေပါတယ်။

ဥပမာ - Car Blackbox, IP base CCTV App လိုမျိုးတွေပါပဲ။

ကိုယ်မသိပဲ Stalkerware သွင်းခံထားရလား သိနိုင်တဲ့ ပုံစံတွေကတော့

- - Device Battery မြန်မြန်ကုန်တာ

- - Device က ခဏလေးသုံးတာနဲ့ ပူလာတာ။ အပူမြန်လာတာ။

- - ကိုယ်မသိတဲ့၊ မြင်ဖူးနေကြ မဟုတ်တဲ့ Process တွေ run နေတာ။

- - Mobile Data usage လိုတာထက် ပိုများနေတာ။

- - Device က တခါတခါ ကိုယ်မလုပ်ရပါပဲ သူ့ဖာသာ သူ restart ကျကျသွားတာ။

- - တချို့ App တွေမှာ အရင် ကိုယ်ပေးထားတဲ့ Permission ထက် ပိုရနေတာ။ (ဥပမာ - GPS location permission ကို off ထားပေမယ့် ပြန်ကြည့်တဲ့ အခါ on နေတာမျိုးပေါ့။)

နောက်ထပ် အသေးစိပ် စစ်ဆေးနိုင်တာကတော့ Device Profile တွေမှာ ကိုယ်မသွင်းထားပဲ ရောက်နေတဲ့ Profile တွေရှိနေလား ဆိုတာ စစ်တာ။

ကိုယ်မရင်းနှီးတဲ့ App တွေ ရှိနေလား စစ်တာမျိုး။ (ဒါကတော့ Cerberus လို Stealth Mode မှာ အလုပ်လုပ်တဲ့ App မျိုးအတွက် သိဖို့ ခက်မှာပါ။)

သက်ဆိုင်ရာ App Store တွေရဲ့ Protect လုပ်ထားတဲ့ App တွေကိုပဲ သုံးတာမျိုးပေါ့။ (ဒါကလဲ ခက်ပါတယ်။ Stalkerware တွေက illegal app တွေ ဖြစ်မနေသေးလို့ပါ။ ဘာလို့လဲ ဆိုတော့ Children Monitor လိုမျိုးအတွက် ဖြစ်နေလို့ လောလောဆယ်ထိ Legal ဖြစ်နေသေးတာပါ။)

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

တယောက်ယောက်က ကိုယ့် Device ထဲကို ရည်ရွယ်ချက်နဲ့ သွင်းထားပေမယ့် သွင်းထားတဲ့ သူ အပြင် Stalkerware App နဲ့ သူ့ Server ရဲ့ လုံခြုံရေးပိုင်း အားနည်းလို့ Hacker တွေ ထိန်းချုပ်တာ ခံရပြီဆိုရင်တော့ မမျှော်လင့်ထားတဲ့ ဆိုးကျိုးတွေနဲ့ ရင်ဆိုင်ကြရမှာပါ။

အားလုံးပဲ Stalkerware App များရန်မှ ပါးပါးနပ်နပ်နဲ့ ရှောင်နိုင်ကြပါစေ။

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

(Be knowledgeable, pass it on then)

How we should think like StepN developer on move2earn apps?

noreply@blogger.com (Mr.blogger) — Tue, 24 May 2022 13:24:00 +0000

၂၀၂၁ ခုနှစ်၊ နိုဝင်ဘာလ မှာ အိုင်ဒီယာတူပြီး စျေးကွက်ထဲမှာ ရှိပြီးသား Application တွေ နဲ့ မတူပဲ တမူ ထူးခြားတဲ့ Web 3.0 Blockchain အခြေပြု “StepN” ဆိုတဲ့ Move to Earn Application တခု ထွက်ပေါ်လာခဲ့ပါတယ်။

ဒီ App ဟာ အရင်ရှိပြီးသားတွေ နဲ့ မတူတာကတော့ အသုံးပြုသူက Runner Shoes, Jogger Shoes, Walking Shoes ဆိုတဲ့ NFT ဖိနပ်တွေ ဝယ်ပြီးလေ့ကျင့်ခန်းလုပ်ရတာပါ။

လေ့ကျင့်ခန်း လုပ်သလောက် GST token ပြန်ရပြီး ရလာတဲ့ Token တွေကို ပြန်ရောင်းခြင်းဖြင့် ဝင်ငွေရစေတာပါ။ လူလဲ ကျန်းမာ၊ ဝင်ငွေလဲ ရ‌ပေါ့။

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

အဲဒီအထဲက Technical Challenge တွေ အကြောင်းကို ကျတော်လဲ ပုံစံတူ Application တခုလုပ်ရင်းက စံနမူနာယူရင်း နဲ့ တခြားကျတော်နဲ့ ရင်ဘတ်ချင်း တူတဲ့သူတွေ ဖတ်မိအောင် ပြန်ဖောက်သည်ချလိုက်ပါတယ်။ StepN App Developer တွေ အနေနဲ့ Technical Challenge 3 ခုကို ဖြေရှင်းခဲ့ရပါတယ်တဲ့။

Technical Challenge 1 – Proof of Movement (POM)

Running Application, Wearable Gadget တွေ မှာ အသုံးပြုသူတွေ မှန်မှန်ကန်ကန် သုံးနေလား၊ လိမ်ညာသုံးနေလား ဆိုတာကို စစ်ဖို့ anti-cheating system ဆိုတာ ထည့်မထားပါဘူး။ ဘာလို့ ထည့်မထားတာလဲ ဆိုတော့ မလိုအပ်လို့ပါ။ ဒါပေမယ့် တနေ့ကို ခြေလှမ်း ဘယ်နှစ်လှမ်း၊ အကွာအဝေး ဘယ်လောက် ရောက်အောင် လျှောက်နိုင်ရင် ဘာပေးမယ် ညာပေးမယ်ဆိုတဲ့ Incentive/Reward Program တွေ ပါလာတဲ့ အခါမှာ အဲ့လို စစ်ဆေးတဲ့ စနစ် မပါတာဟာ လူတွေ လိမ်ညာဖို့ ဖြစ်လာတာပါပဲ။ ဒီအတွက် Proof of Movement ဆိုတာကို ထည့်သွင်းစဉ်းစားကြရပါတယ်။ ဒီပြဿနာကို ပြေလည်အောင် ရှင်းဖို့က Developer တွေဟာ Gravity Sensor အပါအဝင်

· The linear acceleration sensor

· The significant motion sensor

· The accelerometer

· The gyroscope sensor

· The step detector sensor

· The step counter

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

ဒါကြောင့် များပြားလှတဲ့ Sensor တွေရဲ့ အကူအညီ နဲ့ ပိုပြီးတိကျ တဲ့ ရလာဒ် ရဖို့ Three Factor Authentication Process ကို အသုံးပြုကြရပါတယ်။ Three Factor Authentication Process ဆိုတာက Mobile device ရဲ့ လှုပ်ရှားပုံ နဲ့ လူရဲ့ လှုပ်ရှားပုံ ကို pattern ကို စစ်တဲ့ mobile motion matches human movement wavelength၊ Mobile device ရဲ့ လှုပ်ရှားပုံ နဲ့ Mobile device က ရတဲ့ ခြေလှမ်း အရေအတွက် mobile motion matches mobile step counter၊ Mobile device ရဲ့ လှုပ်ရှားပုံ နဲ့ GPS လမ်းကြောင်း mobile motion matches GPS track သုံးခု က ရတဲ့ အချက်အလက်ကို အသုံးချ တာ ကို ဆိုလိုတာပါ။

Technical Challenge 2 – Proof of Distance

အကွာအဝေး အမှန်ကို ရဖို့ကို Step Counter နဲ့ GPS track ကနေ ရနိုင်ပါတယ်။ အဓိက ပြဿနာက Step Counter ကို လွယ်လွယ်ရနိုင်ပေမယ့် GPS က ရတဲ့ အချက်အလက်က ရာနှုန်းပြည့် မမှန်တာပါပဲ။ သစ်ပင်အောက်တို့ ၊ အဆောက်အအုံ တခုခုထဲ ရောက်နေတဲ့ Mobile Device ရဲ့ GPS data ဟာ မမှန်နိုင်ပါဘူး။ စမ်းသပ်ချက်တွေ အရကတော့ အခန်းတခုရဲ့ စားပွဲ‌ပေါ်မှာ တင်ထားတဲ့ Mobile Device ရဲ့ GPS data က အချိန်ကြာလေလေ နေရာ ရွေ့နေလေပါပဲ။ အပြင်မှာ ဆိုရင် ၃ မီတာကနေ မီတာ ၂၀ ထိတောင် ရွေ့နေတတ်ပါတယ်တဲ့။ ဒီ အခြေအနေကို GPS Drifting လို့ ခေါ်ပါတယ်။ GPS က Quality အနေနဲ့ လဲ Degrade ဖြစ်ပါသေးတယ်။ GPS Signal ပျောက်သွားတတ်တာ မျိုး ကြုံဖူးကြမှာပါ။ အဲ့လို ဖြစ်တဲ့ အခါ Re-route/ Re-calculate ပြန်လုပ်ရပါတယ်။ မျဉ်းဖြောင့်အတိုင်း သွားနေတာ မဟုတ်ပဲ အကွေ့ အကောက်နဲ့ သွားနေရင်း GPS Signal ပျောက်သွား တဲ့ အခါ Signal loss ဖြစ်သွားတဲ့ နေရာကနေ ပြန်ပေါ်လာတဲ့ နေရာ Point ၂ ခု ကို GPS က မျဉ်းဖြောင့် အတိုင်း ပြန်တွက်ပါတယ်။ ဒီအခါမှာ မှန်ကန်တိကျ တဲ့ အကွာအဝေးကို မရတော့ပါဘူး။

ဒါကို GPS Degrading ဖြစ်တယ်လို့ ခေါ်ပါတယ်။ မြင့်မားတဲ့ အဆောက်အဉီး တွေ ကြားထဲ ရောက်တဲ့ အခါမှာ GPS Signal တွေက Bounce ဖြစ်တတ်ပါသေးတယ်တဲ့။ အဲ့လိုဖြစ်တဲ့ အခါ Track Distance တွေက ၂ ဆ ၃ ဆ ထိ တက်သွားတတ်ပါတယ်။ အဲ့လို အခြေအနေကို GPS Bounce လို့‌ခေါ်ပါတယ်။ ဒီ GPS ပြဿနာတွေကို GPS drift corrective, environmental factor canceling နဲ့ player route planning algorithms တွေကို သုံး ပြီး ရှင်းကြပါတယ်။

Technical Challenge 3 – Hack Prevention

နောက်ဆုံး တခုကတော့ Android Emulator လို Mobile OS Emulator တွေသုံးပြီး Hack တာကို ရှင်းကြတာပါ။ User Experience ကို ထိခိုက်စေတဲ့ Captcha လိုဟာတွေ သုံးပြီး ဖြေရှင်းဖို့ ကြိုးစားတာတောင် မရခဲ့ပါဘူး။ နောက်ဆုံးမှာတော့ Machine Learning ကို သုံးပြီး ရှင်းခဲ့ရပါတယ်တဲ့။ ကဲ ဒါကတော့ StepN Developer တွေ နဲ့ အားကျနမူနာ ယူစရာကောင်းတဲ့ သူတို့ ရဲ့ Technical Challenge တွေကို ဖြေရှင်းကြပုံပါ။

တခြား Design Challenge အပါအဝင် Server, Storage, Communication စတာတွေ အများကြီး ကို ဖြေရှင်းကြရပါသေးတယ်။

ကျတော်က တော့ ကျန်တာတွေ ထက် အပေါ်က Technical Challenge ၃ ခုကို အရမ်းသဘောကျလို့ ဖတ်မှတ် စရာ တခုအနေနဲ့ မှတ်တမ်းတင်ထားလိုက်တာပါ။

အသေးစိတ် ဖတ်ချင်ရင်တော့ အောက်က လင့်မှာ သွားဖတ်ကြည့်နိုင်ပါတယ်။ https://stepnofficial.medium.com/how-did-we-build-the-worlds-first-move2earn-nft-game-in-four-months-fde4d13dfb18

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

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

(Be knowledgeable, pass it on then)

Metaverse is what!

noreply@blogger.com (Zaw Htet) — Mon, 20 Dec 2021 06:25:00 +0000

AR(Augmented Reality) ရယ်၊ Mirror World ရယ်၊ lifelogging ရယ်၊ Virtual World ရယ် ဆိုတဲ့ လေးခု ပေါင်းလိုက်ရင် အခု ခေတ်စားနေတဲ့ Metaverse ဆိုတာ ဖြစ်လာရော။

ချန်ဒူ CheugDu ဆိုတဲ့ တရုတ်ပြည်မ ကြီးက မြို့တစ်မြို့ ကို Metaverse အဖြစ် ပြောင်းလဲဖန်တီးဖို့ စီစဥ်နေပါတယ်ဆိုပြီး တွေ့မိတယ်။

တကယ်သာဖြစ်လာခဲ့ရင် လူနေထိုင်မှုဘဝ ပုံစံတွေက အခု Video ထဲကအတိုင်း ဖြစ်လာပြီး အကုန် ရူးကုန်ကြတော့မယ်။ 🤣😂

Metaverse ဆိုတဲ့အရာက လက်ရှိလူနေထိုင်မှုကနေ တမူကွဲထွက်လာမဲ့ခေတ်တစ်ခုရဲ့ အစ ဖြစ်လာမလား။

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

ဘာနေနေ ကိုယ်တွေ အိုင်တီသမားတွေကတော့ အပေါ်က (၄) ခု ကို ဖြစ်လာဖို့ Cloud နည်းပညာတွေ၊ Blockchain နဲ့ NFT တွေ ကို ခုကတည်းက လေ့လာမှပဲ ရတော့မယ်။ မဟုတ်ရင် ဗီယက်နမ်တို့ တရုတ်တို့ ရဲ့ ခိုင်းဖတ်ပဲဖြစ်မလား။ သူတို့ရဲ့ Product တွေပဲ အဖြစ်ခံမလား စဉ်းစားပေတော့ပဲ။

ဘာတွေပြောနေလဲ မသိရင် "Memories of the Alhambra" ဆိုတဲ့ ကိုရီးယားကား တကားလောက်ကြည့်လိုက်။ ပြီးရင် "Ready Player One" လို ဇာတ်ကားမျိုးကြည့်လိုက်ရင် နည်းနည်းပေါက်သွားမယ်။ 😅

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

(Be knowledgeable, pass it on then)

How to renew your CCIE by learning and earning credit points from Cisco?

noreply@blogger.com (Zaw Htet) — Wed, 17 Jun 2020 05:38:00 +0000

Cisco သမားတွေအတွက် Cisco က Continuing Education ဆိုတဲ့ Program လုပ်ပေးထားတာ ကြာပါပြီ။

ဘာလဲဆိုတော့ ce.cisco.com ကို သွားပြီး မိမိ Cisco ID နဲ့ Login ဝင်ပါ။

ပြီးရင် အောက်က အတိုင်း Item Catalog ကိုသွားပါ။

Item Catalog အောက်မှာ အောက်ကပုံထဲကလို Training Course တွေမြင်ရပါမယ်။

အဲဒီအထဲကမှ Cisco Learning Services (Direct Delivery) ဆိုတာတွေက Free ပေးထားတာပါ။

ဘေးက Credits ဆိုတာကတော့ သင်ခန်းစာ တခုပြီးလို့ စာမေးပွဲ အောင်တိုင်း ရမယ့် Point တွေပေါ့။

ဒီ Point တွေကို CCIE renewal လုပ်ဖို့ အတွက် သုံးလို့ရပါတယ်။

သင်ခန်းစာ တခုပြီးလို့ လက်မှတ်ရပြီဆိုတဲ့ အခါ point တွေကို claim လုပ်ရပါတယ်။

Claim လုပ်ဖို့အတွက် အောက်မှာ ပြထားသလို Submit Items ကို သွားပါ။

ပြီးရင် ကိုယ်ပြီးမြောက်ခဲ့တဲ့ သင်တန်းနာမည်၊ တက်ခဲ့တဲ့ နေ့နဲ့ ပြီးတဲ့ နေ့ကိုဖြည့်ပြီး Verify လုပ်ထားတဲ့ Completion Certificate ကို Upload တင်ပေးရပါတယ်။

အားလုံးပြီးရင်တော့ Submit လုပ်ပါ။

Submit လုပ်ပြီးတဲ့ အခါ Cisco က ပြန်လာမယ့် Email ကိုစောင့်ပေါ့။

Approve Email ရပြီဆိုရင် မိမိရဲ့ Dashboard မှာ ရထားတဲ့ Credit Point တွေမြင်ရပါပြီ။

Credit Point တွေနဲ့ ချည်းပဲ CCIE ကို renewal လုပ်ချင်ရင်တော့ Point ပေါင်း ၁၂၀ လိုမှာဖြစ်ပါတယ်။

တခြား နည်းလမ်းတွေလဲ ရှိပါသေးတယ်။

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

https://www.cisco.com/c/en/us/training-events/training-certifications/recertification-policy.html#~requirements

ခေါင်းစဉ်မှာ ပြောထားတာကတော့ CCIE အတွက်ဆိုပေမယ့် တခြား Level တွေအတွက်လဲ အကျုံးဝင်ပါတယ်။

အားလုံးပဲ Lifelong Learning လုပ်ရင်းနဲ့ မိမိရဲ့ ကြိုးစားပမ်းစား ရထားတဲ့ လက်မှတ်များကို သက်တမ်းတိုးနိုင်ကြပါစေ။

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

(Be knowledgeable, pass it on then)

AWS CloudFormation Drift

noreply@blogger.com (Zaw Htet) — Mon, 25 May 2020 11:25:00 +0000

AWS ပေါ်မှာ Project လုပ်ကြတဲ့ အခါ CloudFormation သုံးပြီး Resource တွေကို Auto Create လုပ်ကြသလို Manual လဲ Create လုပ်ကြရတဲ့ အခိုက်အတန့်တွေရှိပါတယ်။

WAF လိုဟာမျိုးကို Automation သုံးပြီး Create လုပ်ကြသလို IPS လို AWS Market Place ပေါ်က Third Party Resource တွေကို လဲ Manual Create Setup လုပ်ကြရတာမျိုးပေါ့။

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

ကျတော် Project တွေလုပ်တုန်းကဆိုရင် Team Member အယောက် ၂၀ နီးပါးနဲ့ လုပ်တော့ အကုန်လုံးက Project Timeline အတွင်း Deliver လုပ်နိုင်ဖို့ တချိန်တည်း တပြိုင်တည်း Management Console ကို ဝင်ပြီး လုပ်ကြရတယ်။ Member အကုန်လုံးကလဲ Admin Right ပေးထားမှ အဆင်ပြေတော့ ကြုံရတာတွေက ကိုယ်လုပ်ထားတဲ့ Security Group Rule ကို သူများကဖျက်လိုဖျက် ဝင်ပြင်လို ပြင်၊ WAF Rule တွေကို Condition ပြောင်း သွားလို့ ပြောင်းသွားနဲ့ တိုင်အတော်ပတ်ပါတယ်။

ဒီလို အဖြစ်မျိုးကို ပြန်စစ်ဆေးနိုင်ဖို့ AWS က CloudFormation Drift ဆိုတဲ့ Feature ကို မိတ်ဆက်ပေးထားတာ အတော်ကြာပါပြီ။

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

အောက်က ပုံမှာဆို ကျတော် နမူနာ အနေနဲ့ EC2 Instance တခုနဲ့ အဲ့ဒီ EC2 အတွက် ဘယ် IP ကမဆို SSH ဝင်လို့ရတဲ့ Security Group တခုကို CloudFormation နဲ့ Create လုပ်ထားပါတယ်။

ပြီးတဲ့ အခါ အဲ့ဒီ Security Group ကို ဘယ် IP ကမဆို HTTP ပါ Access ရအောင် ပြင်လိုက်ပါတယ်။

ပြီးတော့မှ CloudFormation Stack ကိုသွားပြီး အောက်ကလို Detect လုပ်ပြီး ဘာတွေ ပြင်သွားတာလဲဆိုတာကို စစ်ကြည့်နိုင်ပါတယ်။

ပုံတွေကို Caption ရေးမပေးတော့ဘူး အပေါ် ကနေ အောက်အထိ CloudFormation Create လုပ်တာကနေ Change Drift တွေကို စစ်တဲ့အထိ အစဉ်လိုက်ပဲ တင်ပေးထားပါတယ်။

ဒါလေးက အတော်အသုံးတည့်တဲ့ အတွက် CloudFormation သမားတွေ သဘောကျမယ်လို့ ထင်ပါတယ်။

တခြား Monitoring and Alert Solution တွေနဲ့ ဒါမျိုးကို Detect and Alert လုပ်နိုင်ပေမယ့် Project လုပ်နေတဲ့အချိန်မျိုးမှာဆိုရင် အဲ့လို Solution တွေက နောက်ဆုံးမှ လုပ်ဖြစ်တာဆိုတော့ ဒီလို Feature မျိုးကိုးပဲ အားကိုးရမယ်ဆိုတာကတော့ မလွဲမသွေပေါ့ဗျာ။

Cloud Resource အကုန်လုံးကိုတော့ Drift က Detect မလုပ်နိုင်သေးပါဘူး။ Limitation တွေရှိပါသေးတယ်။ အသေးစိတ်ကိုတော့ အောက်က လင့်မှာ သွားဖတ်နိုင်ပါတယ်။

https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/using-cfn-stack-drift-resource-list.html

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

(Be knowledgeable, pass it on then)

Why Shared Responsibilities is important on Cloud?

noreply@blogger.com (Zaw Htet) — Mon, 30 Dec 2019 16:10:00 +0000

ကျ တော် CompTIA CySA+ Course လေ့လာတုန်းက သင်တဲ့ ဆရာပြောတာလေးက On-Premise ထက်စာရင် Cloud Service Provider တွေရဲ့ Infra က ပို Secure ဖြစ်တယ်ဆိုတာပါပဲ။

တကယ်လဲမှန်ပါတယ်။

ဒါပေမယ့် Cloud Service ကိုသုံးပြီဆိုတာနဲ့ လိုက်နာရမယ့် Share Responsibilities ဆိုတာရှိပါတယ်။

အောက်ကပုံလေးကို ကြည့်လိုက်ရင် အကျဉ်းအားဖြင့် နားလည်ပါတယ်။

ပိုတိတိကျကျ သိချင်ရင် တော့ လိုက်နာရမယ့် Best Practice တွေကို အတိအကျလိုက်နာဖို့ လိုပါတယ်။

ကျ တော်တို့ Cloud ပေါ်တက်လာပြီး အလုပ် တွေ လုပ်ကြတဲ့ အခါ တော်တော်ကို ကြီးမားတဲ့ အမှားတွေ လုပ်ကြပါတယ်။

ဘာတွေလုပ်တာလဲ ဆိုရင် User Account တွေ ရဲ့ Role နဲ့ Policy ကို Identity Access Management မှာ သေချာ Control မလုပ်ကြပါဘူး။
Network Access Control List မှာ ဘာလာလာ ပေးဝင်တဲ့ အလှူဒါန ရက် ရော ကြပါတယ်။
Security Group တွေ ကို လည်း Upstream , Downstream Security Group တွေနဲ့ Tag မလုပ်ကြပဲ NACL မှာ လို ဘာလာလာ ပေးဝင်တဲ့ အလှူမျိုး ထပ်လုပ်ကြပါတယ်။
ပိုဆိုးတာက တော့ Test EC2 Instance တွေကို Programmatic Access Key တွေ နဲ့ Public က နေ Access လှမ်းလုပ်လို့ရ အောင် လုပ်ထားတာမျိုးပါပဲ။
အလားတူ API Key, SSH Key စတာမျိုးတွေကို Limited Access လုပ်မထားတဲ့ Test EC2 Instance တွေမှာ သိမ်းထားတာပါပဲ။
S3 Bucket တွေကို အလှူပေးထားတာမျိုးတွေလည်း ပါသေးတာပေါ့။
ဒါတွေက လက် တွေ့မှာ အဖြစ်များ အ တွေ့များနေတဲ့ Human Error, Misconfiguration Error တွေပါပဲ။

ဒါမျိုးတွေက ကျ တော်တို့ချည်းပဲ ဖြစ် နေ လုပ် နေတာတော့ မဟုတ်ပြန်ဘူးဗျ။
ထင်သာမြင်သာတဲ့ ဖြစ်ရပ်တခုကို ဥပမာ အ နေနဲ့ ပြရမယ်ဆိုရင် လွန်ခဲ့ တဲ့ လပိုင်းလောက်က ဖြစ်သွားတဲ့ Imperva Security Breach ကိုပဲ အောက်က လင့်က နေ ဖတ်ကြည့်နိုင်ပါတယ်။

Imperva Data Breach Caused by Stolen AWS API Key

ဒီနေ့လို ခေတ်မှာ Scanning/Probing ဆိုတာ လူကိုယ်တိုင်က လုပ် နေစရာ မလိုတော့ပါဘူး။
ဒီတော့ ကိုယ့်က Test လုပ် နေတာပါဆိုပြီး ကိုယ့် Cloud Resource ကို လာသမျှ ပေးဝင်တဲ့ အလှူမျိုး လုပ်ထားလို့က တော့ လူတကာ ဝင် မွှေသွားတာ ခံရပြီး အခန့်မသင့်ရင် Priviliege Escalation, APT စတဲ့ အ မွှေစိန် တွေနဲ့ နဖူးတွေ့ ဒူးတွေ့ ရင်ဆိုင် ရမှာပါ။ ဒါတောင် ဒင်းတို့ ကိုယ့် Infra ထဲရှိနေတယ်ဆိုတာကို ၅ နှစ် လောက် နေမှ သိတာမျိုး ဖြစ်ချင်ဖြစ် နေမှာဗျ။

အ ပြောပဲ ရှိ တာ မဟုတ်ဘူးဗျာ။

မယုံရင် အောက်က လင့်တွေမှာ ကမ္ဘာတလွှားက Cyber Attack တွေရဲ့ Live ကို ကြည့်နိုင်ပါတယ်။ သက်ဆိုင်ရာ Vendor တွေရဲ့ Device Sensor တွေက ပို့ပေးတဲ့ အချက်အလက်ဆိုတော့ အတိအကျ တော့ မရနိုင်ဘူးပေါ့။

Live Cyber Threat Map by Checkpoint

Live Cyber Threat Map by Fortinet

FireEye Cyber Threat Map

Cyber Threat Live Map by Kaspersky

ဒါပါပဲ။

ကိုယ်တိုင်က AWS နဲ့ အဓိက လုပ်နေရလို့ AWS နဲ့ ယှဉ်ပြီး ပြောတာပါ။
ဒါတွေကို Cloud ပေါ်မှာ သတိထားသင့်ပါတယ်။

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

ပျော်ရွှင်ပါစေဗျာ။
(Be knowledgeable, pass it on then)

Infrastructure as code with Terraform on AWS

noreply@blogger.com (Zaw Htet) — Sat, 19 Oct 2019 11:45:00 +0000

Netflix လို ထောင်နဲ့သောင်းနဲ့ ချီတဲ့ AWS Resource တွေကို Manually Manage လုပ်ဖို့ဆိုတာ အတော်ခက်ခဲပါတယ်။
Blue/Green Architecture လိုမျိုး Continuous Integration/Continuous Deployment လုပ်ဖို့ အတွက်ဆို ကျတော်တို့တွေ အရင်လို Manual လုပ်နေလို့မရပါဘူး။

Cloud Computing ခေတ်မှာ Resource တွေက ကြိုက်သလောက်သုံးကျသလောက် ရှင်းပုံစံနဲ့ သွားနေသလို။ Compute/Resource တခုခုကို Start/Stop လုပ်ရတာလဲ အရမ်းကို လွယ်ကူမြန်ဆန်လာပါတယ်။

ဒီတော့ ခုနောက်ပိုင်း Infrastructure as Code ဆိုတာ အရမ်းခေတ်စားလာတော့တာပေါ့။

Cloud ပေါ်မှာ Business Application တခုကို Distributed System, Micro-Service ပုံစံတွေ ဆောက်တဲ့ အခါ Resource တွေကို မြန်မြန်ဆန်ဆန်ဆောက်ပြီး စမ်းကြပါတယ်။ Staging, UAT လို မျိုးက အမြဲတမ်း Run ထားဖို့ မလိုပဲ လိုအပ်တဲ့ အခါမှ Resource တွေကို ချက်ချင်းဆောက်ပြီး Run and Test လုပ်နိုင်လာကြပါပြီ။

ဒီတော့ လိုချင်တဲ့ Infrastructure မျိုးကို Code ရေး၊Template ထုတ်သိမ်းထားပြီး လိုအပ်တဲ့ အချိန်မှာ ကောက် Run လိုက်တဲ့အခါ အချိန်လဲကုန် သက်သာ အမှားကင်းတဲ့ Infra မျိုးရပြီး စမ်းလို့ရတာပေါ့။ စမ်းပြီး မလိုတော့တဲ့ အချိန်မှာလဲ Resource တွေကို Terminate လုပ်ပြီး ငွေကြေးကုန်ကျမှုကို ခြွေတာနိုင်ပါသေးတယ်။

ဒီအတွက် Infra as a code ဆိုတာဘာလဲ။ ဘယ်လိုမျိုးလဲဆိုတာ သိရအောင် အောက်က Youtube Video မှာ ကျတော်က Terraform ကို သုံးပြီး AWS ပေါ်မှာ VPC, Subnet နဲ့ EC2 Instance တွေကို အခြေခံ နမူနာ ဆောက်ပြထားပါတယ်။

https://youtu.be/dkJ1fr8-6h0

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

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

(Be knowledgeable, pass it on then)

Installing Python, Paramiko and Netmiko on Windows

noreply@blogger.com (Zaw Htet) — Tue, 17 Sep 2019 03:39:00 +0000

Python နဲ့ပတ်သက်ပြီး Video Tutorial တွေ၊ Blog post တွေထဲမှာ ရှင်းပြထားတာက Program ကို Linux ပေါ်မှာ Run ပြတာပါပဲ။ ကိုယ်တွေလိုက်လုပ်ရင်လဲ Emulator, Simulator ပေါ်မှာတော့ Linux နဲ့ စမ်းတာပေါ့။ ဒါပေမယ့် ကျတော်တို့ ကြုံရတဲ့ ပြဿနာက တကယ့် Real World မှာ သုံးချင်တဲ့ အခါ လုပ်ငန်းခွင်သုံး တွေက Windows အများဆုံး ဖြစ်နေတာပါပဲ။

ဒီတော့ Network သမားတယောက်ရဲ့ Windows System ပေါ်မှာ Python နဲ့ သူ့ကို Run ဖို့ လိုအပ်တဲ့ Module တွေ ဘယ်လို Install လုပ်လဲ ဆိုတာကို ပြန်ဝေမျှချင်ပါတယ်။

ပထမဆုံး Python ကို အောက်က လင့်မှာ Download လုပ်ပြီး Install လုပ်ပါ။ (ဒါကတော့ လွယ်ကူတဲ့ အတွက် Screenshot တွေနဲ့ မပြတော့ပါဘူး။)

https://www.python.org/downloads/

ပြီးတာနဲ့ Anaconda ကို အောက်က လင့်မှာ Download လုပ်ပြီး Install လုပ်ပါ။ (ဒါကတော့ လွယ်ကူတဲ့ အတွက် Screenshot တွေနဲ့ မပြတော့ပါဘူး။)

https://www.anaconda.com/distribution/

နောက်တဆင့်က Windows အတွက် Git ကို အောက်က လင့်မှာ Download လုပ်ပြီး Install လုပ်ပါ။ (ဒါကတော့ လွယ်ကူတဲ့ အတွက် Screenshot တွေနဲ့ မပြတော့ပါဘူး။)

https://www.git-scm.com/download/

လိုတာတွေ Download လုပ်ပြီး Install လုပ်တဲ့ပြီး အခါ Anaconda ရဲ့ Shell ကို Run as administrator နဲ့ ဖွင့်ပြီး အောက်က ပုံတွေမှာ ပြထားတဲ့ Command တခုချင်းစီ ရိုက်ထည့်ပြီး download and install လုပ်ပါ။

၁) Installing Paramiko

၂) Installing SCP

Anaconda နဲ့ အပေါ်က ၂ ခု လုပ်ပြီးတဲ့ အခါ Git Bash Shell ကို Run as administrator နဲ့ ဖွင့်ပြီး Github က Netmiko Repo ကို clone လုပ်ယူပါ။ အောက်က ပုံမှာ ပြထားတဲ့ အတိုင်း Command တွေလိုက်ရိုက်ပြီး လုပ်သွားပါ။

ပြီးရင် အောက်ကပုံထဲက အတိုင်း Python Setup Script ကို install လုပ်ပါ။

အပေါ်က အဆင့်တွေကို ဘာပြဿနာမှ မရှိပဲ လုပ်ပြီးပြီဆိုရင် Command Prompt ဖွင့်ပြီး အောက်ကပုံထဲကလို Python ကို ဝင်ပြီး Paramiko နဲ့ Netmiko Module တွေ Import လုပ်ထားပြီး မပြီး စစ်နိုင်ပါတယ်။

ပုံထဲကလို တွေ့ပြီဆိုရင်တော့ Python Program တွေ သုံးဖို့ အဆင်သင့်ဖြစ်ပါပြီ။

Paramiko နဲ့ Netmiko ကို Windows မှာ ဘယ်လို Install လုပ်ရလဲ နဲ့ import netmiko , import paramiko တွေ run တိုင်း ပေါ်လာတဲ့ error တွေကြောင့် ခေါင်းကိုက်ရခြင်း ကင်းဝေးကြပါစေ။

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

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

(Be knowledgeable, pass it on then)

What are AWS VPC Endpoints and when to use them?

noreply@blogger.com (Zaw Htet) — Sun, 15 Sep 2019 08:12:00 +0000

ကျတော်တို့ အိုင်တီလောက မှာ least privilege access ဆိုတာ အရေးကြီးပါတယ်။

ဒါက On-premise မှာတင် သုံးဖို့ မဟုတ်ပဲ Cloud ပေါ်ထိ သက်ရောက်ပါတယ်။

ကျတော်တို့ AWS VPC တခုဆောက်တဲ့ အခါ Public, Private Subnet တွေထဲက Instance တခု သို့မဟုတ် များစွာသော Instance တွေအတွက် ကိုယ့် VPC အပြင်ဖက်မှာ ရှိတဲ့ AWS Service တွေရဲ့ API တွေကို Access လုပ်ဖို့ လိုပါတယ်။ ဥပမာ အနေနဲ့ Amazon S3 , DynamoDB နဲ့ Kinesis တို့လိုပေါ့။

ဒီအခါ မှာ ပုံမှန်ဆိုရင် ကိုယ့် VPC ထဲက Instance တွေက အပေါ်က Service API တွေကို Access လုပ်ဖို့ Internet ကိုထွက်ပြီး Access လုပ်ရမယ်ပေါ့။

ဒါကို ကျတော်တို့က မလိုချင်ဘူးဗျာ။ အကောင်းဆုံး အကြောင်းပြချက်တချို့ကို ပြရမယ်ဆိုရင် လုံခြုံရေးအရရယ်၊ Latency , Speed နဲ့ Bandwidth အသုံးပြုမှုတွေပေါ့။ ဒါတွေကြောင့် ကျတော်တို့က ကိုယ့် VPC ထဲက Instance တွေ Internet ပေါ်တက်ပြီး S3 တို့ဘာတို့ကို Access လုပ်စရာ မလိုပဲ သုံးဖို့ AWS VPC Endpoint ဆိုတာ ပေါ်လာတာပေါ့။

AWS VPC Endpoint မှာ
- Gateway VPC Endpoint နဲ့
- Interface VPC Endpoint ဆိုပြီး နှစ်မျိုးရှိပါတယ်။

Gatway VPC Endpoint ကတော့ ရှင်းပါတယ်။ တခုထက်ပိုတဲ့ Instance တွေ VPC အပြင်က Service API တွေကို သုံးချင်တဲ့ အခါ သုံးတာပေါ့။

အောက်က ပုံမှာလို Subnet 2 က Instance တွေ S3 ကို Access လုပ်သလိုမျိုးပေါ့။

Interface VPC Endpoint ကတော့ အောက်ကပုံထဲကလို Subnet 1 က Instance တခုထဲ အတွက် သုံးတာမျိုးဗျ။

VPC Endpoint ကို သုံးလိုက်ရင် လိုတာထက်ပြီး Access ပေးရတဲ့ VPC Peering တွေလဲ မသုံးပဲနေလို့ရတယ်။

သူ့ကို တခြား AWS Service တွေလိုပဲ Identity Access Management သုံးပြီး Role, Policy တွေ နဲ့ Access Control လုပ်နိုင်ပါသေးတယ်။

ဒါကတော့ VPC Endpoint တွေအကြောင်း ယေဘုယျ ရှင်းပြတာပါ။
ပိုပြီး အသေးစိတ်သိချင်ရင်တော့ အောက်က AWS Website ရဲ့ VPC Endpoint FAQ page မှာ လေ့လာနိုင်ပါတယ်။

https://aws.amazon.com/vpc/faqs/

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

ပျော်ရွှင်ပါစေဗျာ။
(Be knowledgeable, pass it on then)

Automating Web Application Firewall Creation in AWS

noreply@blogger.com (Zaw Htet) — Sun, 08 Sep 2019 03:58:00 +0000

Web Application Firewall တခု မှာ ဝင်လာတဲ့ Web Request Traffic ကို စစ်ဖို့

- - Conditions

- - Rules

- - Web Access List

- - Default Action ဆိုပြီး အစိတ်အပိုင်း (၄) ပိုင်းပါပါတယ်။

Conditions မှာတော့ Cross-Side Scripting, Geo Match, IP Blacklist, SQL Injection, Packet Size Constraint နဲ့ Regular String Match စတာတွေ ပါပြီး၊ Conditions ပေါင်း များစွာကို ပေါင်းပြီး condition တခုအနေနဲ့ configure လုပ်ထားနိုင်ပါတယ်။

Rule မှာတော့ အပေါ်က Conditions တွေကို ထပ်ပေါင်းပြီး configure လုပ်နိုင်ပါသေးတယ်။

Web Access List ကျတော့မှ Rule တွေကို Top-Down ပုံစံ configure လုပ်ရတာပါ။

နောက်ဆုံး Default Action ဆိုတာကတော့ ကျတော်တို့ Firewall တို့ရဲ့ ထုံးစံအတိုင်း Implicit Deny/Permit ကို သတ်မှတ်ပေးရတာပါ။

ဒီတော့ Web Application Firewall တခုလုပ်တော့မယ်ဆိုရင် အပေါ်က အချက်တွေ တခုချင်းစီကို Configure လုပ်ရပါတယ်။

အဲ့ဒီလို လုပ်တဲ့ အခါ ကိုယ့် Web Application တခုချင်းစီအတွက် Condition, Rule, Access List တွေ setup လုပ်ရတာ အတော်ကို အချိန်ယူပါတယ်။

တခုထက်ပိုများတဲ့ Web Application တွေအတွက်ဆိုရင် ပိုဆိုးတာပေါ့။

ဒီတော့ အချိန်ကုန်သက်သာအောင် AWS ပေါ်မှာ Open Web Application Security Project (OWASP) ရဲ့ Top Ten WAF Rules နဲ့ AWS WAF ကို CloudFormation သုံးပြီး ဘယ်လို Auto Implementation လုပ်လဲ ဆိုတာ ပြပါမယ်။

ပထမဆုံး လိုတာကတော့ OWASP Top Ten WAF Rule တွေပါတဲ့ YAML Template ကို အောက်က လင့်မှာ Download လုပ်ပါ။

https://s3.us-east-2.amazonaws.com/awswaf-owasp/owasp_10_base.yml

ပြီးရင်

- AWS Management Console ကို သွားပြီး Login ဝင်ပါ။

- CloudFormation ကို သွားပါ။ အရင်က ဖွင့်မထားဘူးရင် Search မှာ ရှာလို့ရပါတယ်။

- Create stack ကို နှိပ်ပါ။

- Template is ready ကို နှိပ်ပြီး Template Source နေရာမှာ S3 URL ကနေ ပဲ ယူ မလား။ Download လုပ်ထားတဲ့ YAML Template ကိုပဲ သုံးမလားရွေးပါ။

စမ်းချင်တာဆိုရင် တော့ အပေါ်မှာ ပြောခဲ့ တဲ့ လင့်ကိုပဲ S3 URL မှာ ထည့်လိုက်ရင် ရပါတယ်။

Customize လုပ်ချင်ရင်တော့ YAML Template ကို ပြင်ပြီးတော့မှ Upload လုပ်ပြီး Next နှိပ်ပါ။

- Stack Name, Prefix နဲ့ WAF ကို ဘယ်မှာထားချင်တာလဲ (Global လား Regional လား) စတာတွေကို မိမိ လိုချင်တဲ့ အတိုင်း ထည့်ပြီး Next နှိပ်ပါ။

- Stack Name, Tagging တွေနဲ့ IAM Role တွေ နဲ့ တခြား မိမိ Customize လုပ်ချင်တဲ့ Setting တွေရှိရင် ထည့်ပြီး Next နှိပ်ပါ။

နောက်ဆုံး အဆင့်မှာတော့ ကိုယ့် WAF က ကိုယ်လိုချင်တဲ့ Setting တွေအတိုင်း ဟုတ်မဟုတ် စစ်ပြီး Create Stack ကို နှိပ်ပြီး Stack Creation ပြီးတဲ့ အထိစောင့်ပါ။

၁၅ မိနစ်ကနေ မိနစ် ၃၀ အတွင်းမှာ WAF ရလာပါလိမ့်မယ်။

ဒါဆို ရင် ပုံမှန် အတိုင်း Manual ဆောက်မယ်ဆိုရင် ၃ နာရီလောက်ကြာနိုင်မယ့် Web Application Firewall ကို CloudFormation နဲ့ ဆောက်လိုက်တဲ့ အခါ နာရီဝက်လောက်နဲ့ ပြီးသွားတာကို တွေ့ရမှာပဲ ဖြစ်ပါတယ်။

ဒါက ကျတော် Demo အနေနဲ့ အလွယ်ဆုံး အရိုးရှင်းဆုံး လုပ်ပြတာပါ။

တကယ်လို့ ပိုမိုပြည့်စုံပြီး တိကျတဲ့ OWASP Top (10) Base WAF တခု လိုချင်ရင်တော့ YAML Template ကို မိမိစိတ်ကြိုက်ပြင်ပြီး တော့မှ Stack လုပ်ပေါ့။ တခုသိထားရမှာက WAF နဲ့ သူ့ရဲ့ အစိတ်အပိုင်းတွေက Create လုပ်ပြီးသွားရင် ပြန်ပြင်လို့ မရပါဘူး။ နာမည်လေးတောင် ပြင်လို့မရပါဘူး။ ဖျက်လို့ပဲ ရပါတယ်။ ဒါကြောင့် Create မလုပ်ခင် မိမိစိတ်ကြိုက် သေချာ ပြင်ပါလို့ အကြံပေးချင်ပါတယ်။

နောက်ဆုံး တခု ပြောချင်တာက WAF က AWS မှာ Free မဟုတ်ပါဘူး။ Free-Tier သမားတွေ သတိထားဖို့ပါ။ Create လုပ်ပြီးတာနဲ့ Rule တခုစီအတွက် ပိုက်ဆံ စ ကောက်တာပါ။ စမ်းချင်ရင်တော့ မြန်မြန်စမ်းပြီး မြန်မြန်ဖျက်ဖို့ မမေ့ပါနဲ့။ မေ့ရင်တော့ ကိုယ့်ဒေါသနဲ့ ကိုယ်ပေါ့ဗျာ။

Screenshot လေးတွေ သေးပြီး မမြင်ရရင် တပုံချင်းစီ ကလစ်နှိပ်ပြီးကြည့်ပါဗျာ။

ပုံအကြီးတွေတင်ရင် Blog Template နဲ့ မဆန့်လို့ပါ။

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

(Be knowledgeable, pass it on then)

Payment Card Industry Data Security Standard (PCI DSS)

noreply@blogger.com (Zaw Htet) — Thu, 09 May 2019 08:18:00 +0000

Master, Visa, American Express, JCB အစရှိတဲ့ Credit Card တွေနဲ့ ကိုယ့် Infra နဲ့ ချိတ်ဆက် အလုပ်လုပ်ရတော့မယ်ဆိုရင် PCI DSS ဆိုတာကြီးကို ခေါင်းထဲ ထည့်ထားရပါတယ်။

အဲလို Industry အတွက် Network Design လုပ်တဲ့ အခါ သတ်မှတ်ထားတဲ့ PCI Level နဲ့ PCI Requirement ဆိုတာတွေကို အခြေခံလောက်တော့ သိထားဖို့လိုပါတယ်။

ဒီအတွက် ကျတော် အနည်းငယ် ပြန်လည်ဝေမျှချင်ပါတယ်။

PCI DSS ကောင်စီက PCI Level ကို

Level 1 - တနှစ်ကို Credit Card Transaction ပေါင်း ၆ မီလီယံ နဲ့ အထက်

Level 2 - တနှစ်ကို Credit Card Transaction ပေါင်း ၁ မီလီယံ နဲ့ ၆ မီလီယံ ကြား

Level 3 - တနှစ်ကို Credit Card Transaction ပေါင်း ၂ သောင်း နဲ့ ၁ မီလီယံ ကြား

Level 4 - တနှစ်ကို Credit Card Transaction ပေါင်း ၂ သောင်း အောက်

ဆိုပြီး ၄ မျိုး ခွဲထားပါတယ်။

PCI DSS ကောင်စီရဲ့ Requirement တွေကို Compliant ဖြစ်ဖို့ အတွက်ဆိုရင် အောက်က အခြေခံ ၁၂ ချက်လိုပါတယ်။

၁) Data Protection အတွက် Firewall ရှိရပါမယ်။
၂) Vendor ရဲ့ Default Configuration, Default User Account, Password တွေ မသုံးရပါဘူး။ (ဒါကတော့ တော်တော်များများ မလိုက်နာကြပါဘူး :P)
၃) Store လုပ်ထားတဲ့ Data မှန်သမျှ Protection ရှိရပါမယ်။
၄) Cardholder ရဲ့ Data နဲ့ Sensitive အချက်အလက်တွေအားလုံးကို Public Network တွေကနေဖြတ်သန်းစေတဲ့ အခါ Encrypt လုပ်ရပါမယ်။
၅) Antivirus Software တွေ update အမြဲဖြစ်နေရပါမယ်။
၆) Develop လုပ်တဲ့ Infra နဲ့ Application တွေ ကို အမြဲ Secure ဖြစ်နေစေရပါမယ်။ (Plain Text အစား Encrypted Hash password လိုမျိုးပေါ့)
၇) Data Access မှန်သမျှ Access လုပ်သင့်တာထက် လုပ်ဖို့လိုတဲ့သူထက် ပိုမပေးထားရပါဘူး။ (HR က Finance ကို မကြည့်ရသလို။ HR Staff က HR Manager ပဲကြည့်ရတဲ့ Data ကို access မရသင့်သလိုပေါ့)
၈) System Access တွေအတွက် တယောက်ကို ID တခု Unique ID ပဲ ဖြစ်ရပါမယ်။
၉) Cardholder ရဲ့ Data ကို Physically access ရတဲ့နေရာ တိုင်း restricted access ဖြစ်နေရပါမယ်။
၁၀) Infra Resource နဲ့ Cardholder Data တွေ ရဲ့ access လုပ်သမျှကို အမြဲစောင့်ကြည့်နေရပါမယ်။
၁၁) System တွေနဲ့ Process တွေရဲ့ Security ကို ပုံမှန် စစ်ဆေးမှုရှိရပါမယ်။
၁၂) Information Security နဲ့ ပတ်သက်တဲ့ Policy ရှိနေရမှာ ဖြစ်ပြီး အချိန်နဲ့ တပြေးညီ update ဖြစ်နေရပါမယ်။

ဒါတွေကတော့ Credit Card Company တွေ စုပေါင်းဖွဲ့ထားတဲ့ PCI DSS ကောင်စီရဲ့ Requirement တွေပဲ ဖြစ်ပြီး Credit Card Company တခုချင်းစီမှာလဲ သူတို့ ကိုယ်ပိုင် Requirement တွေရှိပါသေးတယ်။

ကျတော်တို့ ပုံမှန် System, Network သမားတွေက PCI DSS ဆိုရင် မြင်ဖူးကြားဖူးပေးမယ့် အပေါ်က PCI DSS requirement တွေကို တော့ သတိမထားမိတတ်ပါဘူး။

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

ပျော်ရွှင်ပါစေဗျာ။
(Be knowledgeable, pass it on then)