Incident — axborot tizimining maxfiyligi, yaxlitligi, mavjudligi yoki kutilgan xizmat ko‘rsatishiga salbiy ta’sir qilgan, yoxud shunday ta’sir ehtimolini yuzaga keltirgan hodisadir. Har bir xato incident bo‘lavermaydi: tashkilot oldindan belgilangan mezonlar asosida hodisaning foydalanuvchi, ma’lumot, xavfsizlik va biznes jarayoniga ta’sirini baholaydi.
Aniqlash va ro‘yxatga olish
Incident monitoring alerti, foydalanuvchi murojaati, audit topilmasi yoki tashqi hamkor xabari orqali aniqlanishi mumkin. Dastlabki yozuvda vaqt, ta’sirlangan xizmat, simptom, reporter, mavjud dalil va hozirgi holat qayd etiladi. Taxminlar faktlardan ajratiladi; hali tasdiqlanmagan sabab incident tavsifida haqiqat sifatida yozilmaydi.
Bir xil muammodan kelgan ko‘plab alert va ticket bitta incidentga bog‘lanadi. Bu takroriy ishni kamaytiradi va yagona timeline yaratadi. Incident identifikatori log, chat, change va post-incident hujjatlarida ishlatiladi.
Ustuvorlik va ta’sir
Severity ta’sir va shoshilinchlikni ifodalaydi. Masalan, bitta ichki foydalanuvchidagi vaqtinchalik nosozlik bilan barcha mijozga ta’sir qilgan ma’lumot sizishi bir xil darajada boshqarilmaydi. Baholashda foydalanuvchilar soni, muhim funksiya, ma’lumot turi, geografiya, regulatory majburiyat va workaround mavjudligi hisobga olinadi.
Severity incident davomida o‘zgarishi mumkin. Dastlab kichik ko‘ringan muammo keng tarqalganligi aniqlansa daraja oshiriladi; ta’sir cheklangani isbotlansa pasaytiriladi. O‘zgarish va uning sababi timelinega yoziladi.
Javob jarayoni
Incident commander qaror va muvofiqlashtirishga, texnik guruh diagnostika va tiklashga, communication owner esa ichki hamda tashqi xabarlarga javob beradi. Rollarni ajratish bir muhandisning bir vaqtda tizimni tuzatish, status yozish va barcha savolga javob berish yukini kamaytiradi.
Javob odatda containment, eradication va recovery bosqichlarini qamrab oladi. Containment zararni cheklaydi: trafikni ajratish, zaif credentialni bekor qilish yoki feature flagni o‘chirish. Eradication sababchi zararli holatni olib tashlaydi. Recovery xizmatni nazoratli tarzda qaytaradi va health metrikalarini kuzatadi.
Aloqa va dalil
Status xabari ma’lum fakt, foydalanuvchiga ta’sir, bajarilgan choralar va keyingi yangilanish vaqtini beradi. Texnik taxmin yoki aybdor qidirishdan saqlaniladi. Xavfsizlik incidentida qonuniy, maxfiylik va disclosure talablari communication rejasiga qo‘shiladi.
Log, memory image, disk artefakti va cloud audit yozuvi dalil bo‘lishi mumkin. Ularni yig‘ishda vaqt sinxronligi, hash, kim olgani va qayerda saqlangani qayd etiladi. Tiklash uchun dalilni shoshilib o‘chirib yuborish keyingi tahlilni imkonsiz qilishi mumkin.
Yopish mezoni
Incident xizmat ishlay boshlagani bilangina yopilmaydi. Ta’sir doirasi aniqlangan, mitigation tekshirilgan, kuzatuv davri tugagan va qolgan ishlar egasi bilan ticketga aylantirilgan bo‘lishi kerak. Keyin blameless review timeline, root cause, yaxshi ishlagan jihat va tizimli choralarni hujjatlashtiradi.
Incident va oddiy o‘zgarish
Rejalashtirilgan maintenance paytidagi kutilgan uzilish incident bo‘lmasligi mumkin, ammo belgilangan oynadan oshish yoki kutilmagan data loss incidentga aylanadi. Near miss real zarar yetkazmagan, lekin nazorat ishlamaganini ko‘rsatgan hodisadir; u ham o‘rganish uchun ro‘yxatga olinadi.
Security event avtomatik ravishda security incident emas. Masalan, muvaffaqiyatsiz bitta login odatiy event, ko‘p account bo‘ylab credential stuffing esa investigation talab qilishi mumkin. Classification mezonlari jamoalar orasida bir xil qo‘llanishi uchun runbook va misollar bilan beriladi. Muhim alertni “false positive” deb yopishdan oldin dalil va closure reason saqlanadi.
Bog‘liq tushunchalar
Incident response, Alert, Root cause analysis, Severity, Containment, Recovery, Post-incident review