How we should think like StepN developer on move2earn apps?

၂၀၂၁ ခုနှစ်၊ နိုဝင်ဘာလ မှာ အိုင်ဒီယာတူပြီး စျေးကွက်ထဲမှာ ရှိပြီးသား 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!

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?

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

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?

ကျ တော် 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)