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)