Incident Response Plan

ተግባራዊ የሚሆንበት: ጁን 2፣ 2026

ይህ Incident Response Plan ("Plan") STANDOUT Inc. ("እኛ") የVATES አገልግሎትን ("አገልግሎት") የሚነኩ security incidents፣ service disruptions እና data breaches እንዴት እንደሚለይ፣ እንደሚመልስ፣ እንደሚያገግምና ከእነሱ እንደሚማር ይገልጻል። Plan NIST SP 800-61 Rev.2 እና ISO/IEC 27035 ይጠቅሳል፣ እና automated monitoring instruments እንደ detection front line የሚያገለግሉበት የንድፍ መርህ ላይ ተገንብቷል።

1. ዓላማና ወሰን

የዚህ Plan ዓላማዎች:

• የአገልግሎቱን availability፣ confidentiality ወይም integrity ሊነኩ የሚችሉ ክስተቶችን በጊዜው ለመለየት።
• ተፅዕኖን የሚቀንሱ containment እና recovery ሂደቶችን ለመግለጽ።
• ለተጎዱ Customers እና regulatory authorities የnotification ግዴታዎችን ለማክበር።
• በstructured post-incident analysis ቀጣይነት ያለው የoperational quality መሻሻል ለማስቻል።

ይህ Plan በአገልግሎቱ production environment (EC2፣ Cloudflare እና ተዛማጅ SaaS providers)፣ ከአገልግሎቱ ወደ upstream AI providers ባለው የግንኙነት መንገድ፣ እና Customer data በሚይዙ ሁሉም storage ላይ ይተገበራል።

2. የIncident ትርጓሜና Severity ምደባ

2.1 የIncident ትርጓሜ

ለዚህ Plan ዓላማ፣ incident ከሚከተሉት አንድ ወይም ከዚያ በላይ የሚዛመድ ማንኛውም ክስተት ነው:

• የተጠረጠረ unauthorized access፣ credential compromise ወይም system intrusion።
• Personal data ጨምሮ የCustomer data unauthorized disclosure፣ alteration ወይም loss።
• የአገልግሎቱን core functionality የሚነካ outage ወይም ጉልህ performance degradation።
• Malware infection፣ ransomware ወይም supply-chain attacks ጨምሮ security threats።
• ሰፊ ተፅዕኖ የሚያስከትል operational error፣ misconfiguration ወይም software defect።

2.2 Severity ምደባ

እያንዳንዱ incident በdetection ጊዜ ከሚከተሉት severity levels አንዱ ይመደባል:

• P1 (Critical): ሙሉ የService outage፣ ወይም personal data የተካተተበት የተረጋገጠ data breach። ፈጣን ምላሽ ይጠይቃል።
• P2 (High): የcore functionality ጉልህ መጓደል፣ ለተወሰኑ Customers አለመገኘት፣ ወይም authentication anomalies። የመጀመሪያ ምላሽ በአንድ ሰዓት ውስጥ ይጠይቃል።
• P3 (Medium): ከፊል functional መጓደል ወይም workarounds ካሉበት performance degradation። በሥራ ሰዓታት ውስጥ ምላሽ ተቀባይነት አለው።
• P4 (Low): ውስን user impact ያላቸው ክስተቶች፣ አነስተኛ log integrity drift፣ ወይም የmonitoring instruments redundancy መቀነስ። በሚቀጥለው የታቀደ review cycle ይታያል።

3. የምላሽ መዋቅር

3.1 ተጠያቂ ወገን

የዚህ Plan ተጠያቂ ወገን የSTANDOUT Inc. Managing Director እና የVATES development ኃላፊ Takuya Aoki ነው። በincident ጊዜ ሁሉም የውሳኔ ስልጣንና የውጪ notification ስልጣን በተጠያቂው ወገን ላይ ይጠናከራል።

3.2 Automated Detection Instruments

አገልግሎቱ ከሚከተሉት instruments የተዋቀረ ሙሉ automated ቀጣይ monitoring posture ይሠራል። ከተጠያቂው ወገን ራሳቸውን ችለው ይሠራሉ፣ threshold conditions ሲሟሉም ፈጣን notification ያስነሳሉ።

• Cloudflare Health Check: production origin-ን ከበርካታ ጂኦግራፊያዊ ቦታዎች በ60-ሰከንድ ክፍተት ይመረምራል።
• HetrixTools: production endpoints-ን ከCloudflare ራሱን ችሎ በሆነ መንገድ ከበርካታ ዓለም አቀፍ ቦታዎች ይከታተላል።
• Sentry: application exceptions-ን በreal time ይይዛል፣ ለተጠያቂው ወገንም ያሳውቃል።
• Cloudflare WAF (Managed Rules + OWASP Core Ruleset): የታወቁ attack patterns በBlock mode ይከለክላል።
• Cloudflare DDoS Protection: DDoS attacks በnetwork layer፣ SSL/TLS layer እና HTTP layer ቀጣይነት ባለውና በራስ-ሰር መልኩ ይቀንሳል።
• Anomaly Detection Batch (systemd timer): audit logs በየአምስት ደቂቃው ይቃኛል፣ ሦስት ምድቦች ይለያል: high request rate፣ high authorization denial rate እና brute-force attempts።
• Rate Limiting: በusage endpoints ላይ Per-tenant request rate limiting እና በauthentication endpoints ላይ IP-based rate limiting፣ ትርፍ traffic በራስ-ሰር ይከለክላል።
• Configurable Security Alerts: Customers የትኞቹ operational events (low balance፣ ከአዲስ ቦታ sign-in፣ blocked access፣ የተደጋገሙ sign-in failures) email notifications እንደሚያስነሱ፣ በper-event sensitivity thresholds መምረጥ ይችላሉ።
• Audit Log Infrastructure: እያንዳንዱን API call በhash-chained፣ tamper-evident audit log (SHA-256፣ per-tenant sequence) ይመዘግባል፣ ለራስ-ገለልተኛ verification entries ያጠናክራል።
• Status Dashboard (9 health pills): audit፣ anomaly፣ GeoIP፣ backup፣ deletion batch፣ catalog coverage፣ reconciliation drift፣ killswitch እና service health በአንድ ማያ ገጽ ላይ ያሳያል።
• Automated Backup: SQLite snapshots በGPG AES-256 ያመሰጥራል፣ 30 daily generations ይይዛል።

3.3 የFront-Line ምላሽን ለAutomation መስጠት

የdetection እና triage ደረጃዎች ከላይ በተጠቀሱ automated instruments እንደ front line ይከናወናሉ። ተጠያቂው ወገን ጣልቃ የሚገባው threshold-exceeding notifications ሲቀበል ብቻ ነው። ይህ ንድፍ 24/7 detection coverage ከተጠያቂው ወገን ቦታ ወይም መገኘት ሳይወሰን በአካል መመስረቱን ያረጋግጣል።

4. የምላሽ ሂደት

4.1 Detection

በክፍል 3.2 ከተገለጹት automated instruments አንዱ ወይም ከዚያ በላይ anomaly ሲለዩ፣ ተጠያቂው ወገን በSentry፣ email እና dashboard alerts ወዲያውኑ ይነገራል። Customer reports በ[email protected] ይቀበላሉ፣ በተመሳሳይ flow ይticket ይደረጋሉ።

4.2 Triage

Notification ሲቀበል፣ ተጠያቂው ወገን የሚከተሉትን በመመርመር severity ያረጋግጣል:

• የተፅዕኖ ወሰን (ሁሉም Customers / የተወሰነ Customer / ነጠላ Instance)።
• Personal data፣ authentication credentials ወይም billing information መጎዳታቸውን።
• የውጪ ምክንያቶች ተሳትፎ (upstream AI provider outages፣ Cloudflare outages፣ AWS outages)።
• ከታወቁ attack patterns ጋር correlation (WAF logs፣ anomaly detection results፣ GeoIP alerts)።

4.3 Containment

በseverity መሠረት፣ ከሚከተሉት containment measures አንድ ወይም ከዚያ በላይ ይተገበራሉ:

• ለፈጣን isolation የተጎዱ Instances በstate machine ማገድ።
• Source IP addresses ወደ deny list መጨመር (per-Customer ወይም global)።
• በJWT jti Bulk session revocation።
• Killswitch ማንቃት (ሙሉ traffic ማቆም፣ የመጨረሻ-አማራጭ እርምጃ)።
• በL7 attacks ላይ Cloudflare "Under Attack Mode" ማንቃት።

4.4 Recovery

ከcontainment በኋላ፣ root causes ይወገዳሉ፣ የሚከተሉትም ይከናወናሉ:

• እንደ ተፈለገ ከbackup መመለስ (ሂደቶች በdocs/RESTORE.md ተመዝግበዋል)።
• የተጎዱ credentials rotation (API keys፣ JWT secrets፣ backup encryption keys ወዘተ)።
• Patches፣ configuration fixes እና code corrections ወደ production መተግበር።
• በstaging እና production environments ላይ Verification።
• በmonitoring instruments ቢያንስ ለ24 ሰዓታት ቀጣይ observation።

4.5 Post-Incident

Recovery ከተረጋገጠ በኋላ፣ ተጠያቂው ወገን:

• Timeline-ን፣ root cause-ን፣ የተፅዕኖ ወሰንን እና response actions-ን ይመዘግባል።
• Preventive measures ይለያል፣ ወደ implementation roadmap ያካትታል።
• እንደ ተፈጻሚነቱ፣ ለተጎዱ Customers እና regulatory authorities ያሳውቃል (ክፍል 5 ይመልከቱ)።
• መሻሻያዎችን ወደ ይህ Plan እና ተዛማጅ operational documents ይመግባል።

5. የCustomer እና Regulatory ማሳወቂያ

5.1 የPersonal Data Breach ማሳወቂያ

የpersonal data unauthorized acquisition፣ loss ወይም disclosure ከተረጋገጠ፣ በሚከተሉት መሠረት ማሳወቂያ እንሰጣለን:

• EU General Data Protection Regulation (GDPR) Article 33: ካወቅንበት በ72 ሰዓታት ውስጥ ለsupervisory authority ማሳወቂያ።
• GDPR Article 34: high risk በተለየበት፣ ለተጎዱ data subjects ያለ ተገቢ ያልሆነ መዘግየት ማሳወቂያ።
• Act on the Protection of Personal Information (ጃፓን): ለPersonal Information Protection Commission ሪፖርትና ለdata subjects ማሳወቂያ፣ በተፈጻሚ cabinet orders እና rules መሠረት።
• ሌሎች ተፈጻሚ የሕግ ክልሎች: በተፈጻሚ ብሔራዊ ወይም ክልላዊ data protection ሕጎች የሚጠየቁ notifications።

5.2 የService Disruption ማሳወቂያ

P1 ወይም P2 ለተመደቡ service disruptions፣ የተጠበቀውን recovery timeline እና ማንኛውንም ጊዜያዊ mitigations ጨምሮ ለተጎዱ Customers ያለ ተገቢ ያልሆነ መዘግየት እናሳውቃለን። የnotification channels [email protected] እና የService administration console ናቸው።

5.3 የማሳወቂያ ዘዴ

Notifications በዋናነት ለCustomer registered address በemail ይደርሳሉ፣ እንደ ተፈለገም በadministration console banners ይደገፋሉ።

6. Post-Mortem እና የመማር ዑደት

P1 ወይም P2 incident ተከትሎ፣ ተጠያቂው ወገን Post-Mortem ያካሂዳል፣ የሚከተሉትን ይመዘግባል። ሰነዱ በውስጥ ይያዛል፣ በጥያቄ ላይም ለCustomers እና auditors ይገለጻል።

• ከdetection እስከ recovery ያለው የክስተቶች Timeline።
• Root cause analysis (technical እና operational factors)።
• የተፅዕኖ ወሰን በቁጥር።
• የresponse process ግምገማ።
• Preventive measures እና target deadlines።

Post-Mortems እንደ Blameless Post-Mortems ይካሄዳሉ፣ በግለሰብ ተጠያቂነት ሳይሆን በstructural improvement ላይ ያተኩራሉ።

7. የPlan ጥገናና ክለሳ

7.1 መደበኛ ክለሳ

ይህ Plan ቢያንስ በዓመት አንዴ፣ እንዲሁም ከማንኛውም ጉልህ incident በኋላ፣ በService architecture ጉልህ ለውጦች ላይ፣ እና በተፈጻሚ ሕጎችና ደንቦች ማሻሻያ ላይ ይከለሳል።

7.2 የክለሳ ታሪክ

የዚህ Plan የክለሳ ታሪክ በውስጥ ይያዛል፣ በጥያቄ ላይም ለCustomers እና auditors ይገለጻል።

8. ያግኙን

Incident ለማሳወቅ ወይም ስለ ይህ Plan ጥያቄዎችን ለማቅረብ:

STANDOUT Inc.
Email: [email protected]

መጨረሻ የተዘመነው: ጁን 2፣ 2026