Incident Response Plan

သက်ရောက်သည့်ရက်: 2026 ခုနှစ် ဇွန်လ 2 ရက်

ဤ Incident Response Plan ("Plan") သည် STANDOUT Inc. ("we", "us") က VATES ဝန်ဆောင်မှု ("Service") ကို သက်ရောက်သော လုံခြုံရေး incident များ၊ ဝန်ဆောင်မှု ပျက်ပြားမှုများနှင့် data breach များကို မည်သို့ တွေ့ရှိ၊ တုံ့ပြန်၊ ပြန်လည်ထူထောင်၊ သင်ခန်းစာ ယူသည်ကို သတ်မှတ်ပါသည်။ ဤ Plan သည် NIST SP 800-61 Rev.2 နှင့် ISO/IEC 27035 ကို ကိုးကားပြီး၊ အလိုအလျောက် စောင့်ကြည့်ရေး ကိရိယာများသည် တွေ့ရှိမှု၏ ရှေ့တန်းအဖြစ် ဆောင်ရွက်သည့် design အခြေခံ မူပေါ်တွင် တည်ဆောက်ထားသည်။

1. ရည်ရွယ်ချက်နှင့် Scope

ဤ Plan ၏ ရည်မှန်းချက်များမှာ:

• Service ၏ ရရှိနိုင်မှု၊ လျှို့ဝှက်မှု သို့မဟုတ် integrity ကို သက်ရောက်နိုင်သော ဖြစ်ရပ်များကို အချိန်နှင့်တစ်ပြေးညီ တွေ့ရှိရန်။
• သက်ရောက်မှုကို အနည်းဆုံး ဖြစ်စေသော ထိန်းချုပ်ခြင်းနှင့် ပြန်လည်ထူထောင်ခြင်း လုပ်ထုံးလုပ်နည်းများကို သတ်မှတ်ရန်။
• သက်ရောက်ခံ Customer များနှင့် ကြီးကြပ်ရေး အာဏာပိုင်များထံ အကြောင်းကြားရန် တာဝန်များကို လိုက်နာရန်။
• စနစ်တကျ incident အလွန် ခွဲခြမ်းစိတ်ဖြာမှုမှတစ်ဆင့် လည်ပတ်မှု အရည်အသွေး စဉ်ဆက်မပြတ် တိုးတက်စေရန်။

ဤ Plan သည် Service ၏ production environment (EC2, Cloudflare နှင့် ဆက်စပ် SaaS provider များ)၊ Service မှ upstream AI provider များသို့ ဆက်သွယ်ရေး လမ်းကြောင်း၊ နှင့် Customer data ကို ကိုင်ဆောင်ထားသော storage အားလုံးအတွက် သက်ဆိုင်ပါသည်။

2. Incident အဓိပ္ပာယ်နှင့် ပြင်းထန်မှု အဆင့်ခွဲခြားခြင်း

2.1 Incident ၏ အဓိပ္ပာယ်

ဤ Plan ၏ ရည်ရွယ်ချက်အတွက်၊ incident ဆိုသည်မှာ အောက်ပါ တစ်ခု သို့မဟုတ် ၎င်းထက်ပိုသော အရာများနှင့် ကိုက်ညီသော ဖြစ်ရပ် မည်သည့်ကိုမဆို ဆိုသည်:

• ခွင့်ပြုချက်မဲ့ access, credential အလျှော့ပေါက်ခြင်း သို့မဟုတ် system ထဲ ကျူးကျော်ဝင်ရောက်ခြင်း သံသယ။
• ကိုယ်ရေး data အပါအဝင် Customer data ၏ ခွင့်ပြုချက်မဲ့ ထုတ်ဖော်ခြင်း၊ ပြောင်းလဲခြင်း သို့မဟုတ် ဆုံးရှုံးခြင်း။
• Service ၏ အဓိက လုပ်ဆောင်ချက်ကို သက်ရောက်သော outage သို့မဟုတ် အရေးပါသော performance ကျဆင်းမှု။
• malware ကူးစက်ခြင်း၊ ransomware သို့မဟုတ် supply-chain attack အပါအဝင် လုံခြုံရေး ခြိမ်းခြောက်မှုများ။
• ကြီးမားသော သက်ရောက်မှု ဖြစ်စေသော လည်ပတ်မှု အမှား၊ misconfiguration သို့မဟုတ် software ချွတ်ယွင်းချက်။

2.2 ပြင်းထန်မှု အဆင့်ခွဲခြားခြင်း

incident တစ်ခုစီကို တွေ့ရှိချိန်တွင် အောက်ပါ ပြင်းထန်မှု အဆင့်များထဲမှ တစ်ခုသို့ ခွဲခြားသည်:

• P1 (Critical): Service အပြည့်အ၀ outage သို့မဟုတ် ကိုယ်ရေး data ပါဝင်သော အတည်ပြုပြီး data breach။ ချက်ချင်း တုံ့ပြန်ရန် လိုအပ်သည်။
• P2 (High): အဓိက လုပ်ဆောင်ချက်၏ အရေးပါသော ထိခိုက်မှု၊ သီးခြား Customer များအတွက် အသုံးပြု၍ မရခြင်း သို့မဟုတ် authentication ပုံမှန်မဟုတ်မှုများ။ တစ်နာရီအတွင်း ကနဦး တုံ့ပြန်မှု လိုအပ်သည်။
• P3 (Medium): တစ်စိတ်တစ်ပိုင်း လုပ်ဆောင်ချက် ထိခိုက်မှု သို့မဟုတ် workaround ရှိသော performance ကျဆင်းမှု။ လုပ်ငန်းချိန်အတွင်း တုံ့ပြန်မှု လက်ခံနိုင်သည်။
• P4 (Low): အသုံးပြုသူ သက်ရောက်မှု အကန့်အသတ်ရှိသော ဖြစ်ရပ်များ၊ အသေး log integrity သွေဖည်မှု သို့မဟုတ် စောင့်ကြည့်ရေး ကိရိယာများ၏ redundancy လျော့ကျမှု။ နောက် စီစဉ်ထားသော review cycle တွင် ကိုင်တွယ်သည်။

3. တုံ့ပြန်မှု ဖွဲ့စည်းပုံ

3.1 တာဝန်ခံ ပုဂ္ဂိုလ်

ဤ Plan ၏ တာဝန်ခံ ပုဂ္ဂိုလ်မှာ STANDOUT Inc. ၏ Managing Director နှင့် VATES ဖွံ့ဖြိုးတိုးတက်မှု အကြီးအကဲ Takuya Aoki ဖြစ်သည်။ incident တစ်ခုအတွင်း ဆုံးဖြတ်ပိုင်ခွင့်နှင့် ပြင်ပ အကြောင်းကြားပိုင်ခွင့် အားလုံးကို တာဝန်ခံ ပုဂ္ဂိုလ်တွင် စုစည်းထားသည်။

3.2 အလိုအလျောက် တွေ့ရှိရေး ကိရိယာများ

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

• Cloudflare Health Check: production origin ကို တည်နေရာ အမြင်ရှုထောင့် အများအပြားမှ 60-second ကြားကာလဖြင့် probe လုပ်သည်။
• HetrixTools: Cloudflare နှင့် သီးခြား လမ်းကြောင်းမှတစ်ဆင့် production endpoint များကို ကမ္ဘာတစ်ဝှမ်း အမြင်ရှုထောင့် အများအပြားမှ စောင့်ကြည့်သည်။
• Sentry: application exception များကို real time ဖမ်းယူ၍ တာဝန်ခံ ပုဂ္ဂိုလ်ထံ အကြောင်းကြားသည်။
• Cloudflare WAF (Managed Rules + OWASP Core Ruleset): သိရှိပြီးသား attack pattern များကို Block mode ဖြင့် ပိတ်ဆို့သည်။
• Cloudflare DDoS Protection: network layer, SSL/TLS layer နှင့် HTTP layer တွင် DDoS attack များကို စဉ်ဆက်မပြတ်နှင့် အလိုအလျောက် ဖြေလျှော့သည်။
• Anomaly Detection Batch (systemd timer): audit log များကို ငါးမိနစ်တိုင်း scan လုပ်၍ အမျိုးအစား သုံးခုကို တွေ့ရှိသည်: high request rate, high authorization denial rate နှင့် brute-force ကြိုးပမ်းမှုများ။
• Rate Limiting: usage endpoint များတွင် tenant အလိုက် request rate limiting နှင့် authentication endpoint များတွင် IP အခြေခံ rate limiting ဖြင့်၊ ပိုလျှံသော traffic ကို အလိုအလျောက် ငြင်းပယ်သည်။
• Configurable Security Alerts: Customer များသည် မည်သည့် လည်ပတ်မှု ဖြစ်ရပ်များ (low balance, နေရာအသစ်မှ sign-in, ပိတ်ဆို့ခံ access, ထပ်ခါတလဲလဲ sign-in မအောင်မြင်မှု) က email notification အစပျိုးမည်ကို၊ ဖြစ်ရပ်အလိုက် အာရုံခံနိုင်စွမ်း threshold များဖြင့် ရွေးနိုင်သည်။
• Audit Log Infrastructure: API call တိုင်းကို hash-chain ချိတ်ဆက်ထားသော၊ ပြောင်းလဲမှု သိသာသော audit log (SHA-256, tenant အလိုက် sequence) တွင် မှတ်တမ်းတင်ပြီး၊ သီးခြား စိစစ်အတည်ပြုနိုင်ရန် entry များကို စုစည်းသည်။
• Status Dashboard (9 health pills): audit, anomaly, GeoIP, backup, deletion batch, catalog coverage, reconciliation drift, killswitch နှင့် service health ကို မျက်နှာပြင်တစ်ခုတည်းတွင် မြင်သာစေသည်။
• Automated Backup: SQLite snapshot များကို GPG AES-256 ဖြင့် encrypt လုပ်၍ နေ့စဉ် 30 မျိုးဆက် ထိန်းသိမ်းသည်။

3.3 ရှေ့တန်း တုံ့ပြန်မှုကို Automation သို့ လွှဲအပ်ခြင်း

တွေ့ရှိခြင်းနှင့် triage အဆင့်များကို အထက်ပါ အလိုအလျောက် ကိရိယာများက ရှေ့တန်းအဖြစ် ဆောင်ရွက်သည်။ တာဝန်ခံ ပုဂ္ဂိုလ်သည် threshold ကျော်လွန် အကြောင်းကြားချက် ရရှိမှသာ ဝင်ရောက်ဆောင်ရွက်သည်။ ဤ design သည် တာဝန်ခံ ပုဂ္ဂိုလ်၏ တည်နေရာ သို့မဟုတ် ရရှိနိုင်မှုအပေါ် မမှီခိုဘဲ 24/7 တွေ့ရှိမှု လွှမ်းခြုံမှုကို ရုပ်ပိုင်းအရ တည်ဆောက်ထားကြောင်း သေချာစေသည်။

4. တုံ့ပြန်မှု လုပ်ငန်းစဉ်

4.1 တွေ့ရှိခြင်း

Section 3.2 တွင် ဖော်ပြထားသော အလိုအလျောက် ကိရိယာ တစ်ခု သို့မဟုတ် ၎င်းထက်ပိုသည်က ပုံမှန်မဟုတ်မှုကို တွေ့ရှိသောအခါ၊ တာဝန်ခံ ပုဂ္ဂိုလ်ထံ Sentry, email နှင့် dashboard alert မှတစ်ဆင့် ချက်ချင်း အကြောင်းကြားသည်။ Customer အစီရင်ခံချက်များကို [email protected] တွင် လက်ခံ၍ တူညီသော flow ဖြင့် ticket လုပ်သည်။

4.2 Triage

အကြောင်းကြားချက် လက်ခံရရှိသည်နှင့်၊ တာဝန်ခံ ပုဂ္ဂိုလ်သည် အောက်ပါတို့ကို စစ်ဆေး၍ ပြင်းထန်မှုကို အတည်ပြုသည်:

• သက်ရောက်မှု အတိုင်းအတာ (Customer အားလုံး / သီးခြား Customer / တစ်ဦးချင်း Instance)။
• ကိုယ်ရေး data, authentication credentials သို့မဟုတ် billing အချက်အလက် သက်ရောက်ခံရ/မရ။
• ပြင်ပ အကြောင်းရင်းများ ပါဝင်မှု (upstream AI provider outage, Cloudflare outage, AWS outage)။
• သိရှိပြီးသား attack pattern များနှင့် ဆက်စပ်မှု (WAF log, anomaly detection ရလဒ်, GeoIP alert)။

4.3 ထိန်းချုပ်ခြင်း

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

• ချက်ချင်း ခွဲထုတ်ရန် state machine မှတစ်ဆင့် သက်ရောက်ခံ Instance များကို ဆိုင်းငံ့ခြင်း။
• source IP address များကို deny list သို့ ထည့်ခြင်း (Customer အလိုက် သို့မဟုတ် global)။
• JWT jti ဖြင့် session များကို အစုလိုက် revoke လုပ်ခြင်း။
• killswitch ကို အသက်သွင်းခြင်း (traffic အပြည့်အ၀ ရပ်တန့်ခြင်း၊ နောက်ဆုံး အစီအမံ)။
• L7 attack များကို ဆန့်ကျင်ရန် Cloudflare "Under Attack Mode" ကို အသက်သွင်းခြင်း။

4.4 ပြန်လည်ထူထောင်ခြင်း

ထိန်းချုပ်ပြီးနောက်၊ အရင်းခံ အကြောင်းရင်းများကို ဖယ်ရှား၍ အောက်ပါတို့ကို ဆောင်ရွက်သည်:

• လိုအပ်သလို backup မှ ပြန်လည် ရယူခြင်း (လုပ်ထုံးလုပ်နည်းများကို docs/RESTORE.md တွင် မှတ်တမ်းတင်ထား)။
• သက်ရောက်ခံ credential များ (API key, JWT secret, backup encryption key စသည်) ကို rotation လုပ်ခြင်း။
• patch, configuration ပြင်ဆင်ချက်နှင့် code ပြင်ဆင်ချက်များကို production သို့ ကျင့်သုံးခြင်း။
• staging နှင့် production environment များတွင် စိစစ်အတည်ပြုခြင်း။
• စောင့်ကြည့်ရေး ကိရိယာများမှတစ်ဆင့် အနည်းဆုံး 24 နာရီ ဆက်လက် စောင့်ကြည့်ခြင်း။

4.5 Incident အလွန်

ပြန်လည်ထူထောင်မှု အတည်ပြုပြီးနောက်၊ တာဝန်ခံ ပုဂ္ဂိုလ်သည်:

• timeline, အရင်းခံ အကြောင်းရင်း, သက်ရောက်မှု အတိုင်းအတာနှင့် တုံ့ပြန်မှု လုပ်ဆောင်ချက်များကို မှတ်တမ်းတင်သည်။
• ကာကွယ်ရေး အစီအမံများကို ဖော်ထုတ်၍ implementation roadmap ထဲသို့ ပေါင်းစပ်သည်။
• သက်ဆိုင်သလို၊ သက်ရောက်ခံ Customer များနှင့် ကြီးကြပ်ရေး အာဏာပိုင်များထံ အကြောင်းကြားသည် (Section 5 ကို ကြည့်ပါ)။
• တိုးတက်မှုများကို ဤ Plan နှင့် ဆက်စပ် လည်ပတ်မှု စာရွက်စာတမ်းများထဲသို့ ပြန်လည် ထည့်သွင်းသည်။

5. Customer နှင့် ကြီးကြပ်ရေး အကြောင်းကြားခြင်း

5.1 ကိုယ်ရေး Data Breach အကြောင်းကြားခြင်း

ကိုယ်ရေး data ၏ ခွင့်ပြုချက်မဲ့ ရယူခြင်း၊ ဆုံးရှုံးခြင်း သို့မဟုတ် ထုတ်ဖော်ခြင်းကို အတည်ပြုပါက၊ အောက်ပါတို့နှင့်အညီ အကြောင်းကြားပါသည်:

• EU General Data Protection Regulation (GDPR) Article 33: သိရှိပြီး 72 နာရီအတွင်း supervisory authority ထံ အကြောင်းကြားခြင်း။
• GDPR Article 34: high risk ကို ဖော်ထုတ်ပါက၊ သက်ရောက်ခံ data subject များထံ မလျော့မတန် နှောင့်နှေးခြင်း မရှိဘဲ အကြောင်းကြားခြင်း။
• Act on the Protection of Personal Information (Japan): သက်ဆိုင်ရာ cabinet order နှင့် rule များနှင့်အညီ၊ Personal Information Protection Commission ထံ အစီရင်ခံခြင်းနှင့် data subject များထံ အကြောင်းကြားခြင်း။
• အခြား သက်ဆိုင်ရာ တရားစီရင်ပိုင်ခွင့်များ: သက်ဆိုင်ရာ နိုင်ငံ သို့မဟုတ် ဒေသဆိုင်ရာ data protection ဥပဒေများက လိုအပ်သော အကြောင်းကြားချက်များ။

5.2 ဝန်ဆောင်မှု ပျက်ပြားမှု အကြောင်းကြားခြင်း

P1 သို့မဟုတ် P2 အဖြစ် ခွဲခြားထားသော ဝန်ဆောင်မှု ပျက်ပြားမှုများအတွက်၊ မျှော်မှန်း ပြန်လည်ထူထောင်မှု timeline နှင့် ကြားကာလ ဖြေလျှော့မှုများ အပါအဝင်၊ သက်ရောက်ခံ Customer များထံ မလျော့မတန် နှောင့်နှေးခြင်း မရှိဘဲ အကြောင်းကြားသည်။ အကြောင်းကြားမှု လမ်းကြောင်းများမှာ [email protected] နှင့် Service administration console ဖြစ်သည်။

5.3 အကြောင်းကြားနည်း

အကြောင်းကြားချက်များကို အဓိကအားဖြင့် Customer ၏ မှတ်ပုံတင်ထားသော လိပ်စာသို့ email ဖြင့်၊ လိုအပ်သလို administration console အတွင်း banner ဖြင့် ဖြည့်စွက်၍ ပေးပို့သည်။

6. Post-Mortem နှင့် သင်ယူမှု Cycle

P1 သို့မဟုတ် P2 incident တစ်ခု ပြီးနောက်၊ တာဝန်ခံ ပုဂ္ဂိုလ်သည် Post-Mortem ပြုလုပ်၍ အောက်ပါ အချက်များကို မှတ်တမ်းတင်သည်။ ထို စာရွက်စာတမ်းကို အတွင်းပိုင်း ထိန်းသိမ်းပြီး၊ တောင်းဆိုပါက Customer များနှင့် auditor များထံ ထုတ်ဖော်သည်။

• တွေ့ရှိချိန်မှ ပြန်လည်ထူထောင်ချိန်အထိ ဖြစ်ရပ်များ၏ timeline။
• အရင်းခံ အကြောင်းရင်း ခွဲခြမ်းစိတ်ဖြာမှု (နည်းပညာနှင့် လည်ပတ်မှု အချက်များ)။
• ပမာဏ သတ်မှတ်ထားသော သက်ရောက်မှု အတိုင်းအတာ။
• တုံ့ပြန်မှု လုပ်ငန်းစဉ်၏ အကဲဖြတ်ချက်။
• ကာကွယ်ရေး အစီအမံများနှင့် ပစ်မှတ် နောက်ဆုံးရက်များ။

Post-Mortem များကို တစ်ဦးချင်း တာဝန်ခံမှုထက် ဖွဲ့စည်းပုံဆိုင်ရာ တိုးတက်မှုကို အာရုံစိုက်သော Blameless Post-Mortem များအဖြစ် ဆောင်ရွက်သည်။

7. Plan ထိန်းသိမ်းမှုနှင့် Review

7.1 အချိန်အခါအလိုက် Review

ဤ Plan ကို အနည်းဆုံး နှစ်စဉ်၊ ထို့အပြင် အရေးပါသော incident တစ်ခုပြီးတိုင်း၊ Service architecture ၏ အရေးပါသော ပြောင်းလဲမှုများတွင်၊ နှင့် သက်ဆိုင်ရာ ဥပဒေနှင့် စည်းမျဉ်းများ ပြင်ဆင်ချိန်တွင် review လုပ်သည်။

7.2 ပြင်ဆင်မှု မှတ်တမ်း

ဤ Plan ၏ ပြင်ဆင်မှု မှတ်တမ်းကို အတွင်းပိုင်း ထိန်းသိမ်းပြီး၊ တောင်းဆိုပါက Customer များနှင့် auditor များထံ ထုတ်ဖော်သည်။

8. ဆက်သွယ်ရန်

incident တစ်ခု အစီရင်ခံရန် သို့မဟုတ် ဤ Plan အကြောင်း မေးမြန်းရန်:

STANDOUT Inc.
Email: [email protected]

နောက်ဆုံး မွမ်းမံချိန်: 2026 ခုနှစ် ဇွန်လ 2 ရက်