Vulnerability

Vulnerability — software, hardware, configuration, process yoki design’dagi weakness bo‘lib, undan foydalanilganda confidentiality, integrity yoki availability buzilishi mumkin. Vulnerability real product yoki tizimdagi konkret zaif holatni ifodalaydi.

Har bug security vulnerability emas. Bug faqat noto‘g‘ri behavior yaratishi mumkin, vulnerability esa attacker yoki noto‘g‘ri actor undan security ta’sir olish imkoniga ega bo‘lishini anglatadi.

Weakness va vulnerability

Weakness umumiy xato turidir.

Vulnerability esa ma’lum systemdagi konkret holat.

Masalan:

CWE → weakness turi
CVE → konkret ommaga ma’lum vulnerability

Bitta weakness turidan turli productlarda ko‘plab vulnerability paydo bo‘lishi mumkin.

Threat

Threat — zarar yetkazishi mumkin bo‘lgan actor, hodisa yoki sharoit.

Misollar:

• cyber attacker;
• insider;
• malware;
• tabiiy ofat;
• noto‘g‘ri operation;
• supply-chain compromise.

Vulnerability mavjud bo‘lsa threat undan foydalanishi mumkin.

Exploit

Exploit vulnerability’dan foydalanish usuli yoki code’i.

Zaiflik mavjud, lekin exploit hali yaratilmagan bo‘lishi mumkin.

Exploit public bo‘lgach attack ehtimoli oshishi mumkin.

Biroq exploit mavjudligi real muhitda barcha precondition bajarilganini anglatmaydi.

Risk

Risk vulnerability, threat ehtimoli va business ta’sir kombinatsiyasidir.

Bir xil zaiflik:

• internet-facing payment serverda yuqori risk;
• o‘chiq laboratoriya hostida pastroq risk

bo‘lishi mumkin.

Severity va risk bir xil tushuncha emas.

Exposure

System zaif bo‘lsa ham attacker unga yetib bora olmasligi mumkin.

Exposure:

• internet;
• internal network;
• VPN;
• local user;
• physical access;
• file import;
• partner integration

orqali baholanadi.

Network segmentatsiyasi exposure’ni kamaytiradi, ammo vulnerability’ni yo‘q qilmaydi.

Software vulnerability

Code yoki design xatosi:

• injection;
• memory corruption;
• broken access control;
• unsafe deserialization;
• race condition;
• logic error;
• cryptographic misuse

ko‘rinishida bo‘lishi mumkin.

Source code review va security testing topishga yordam beradi.

Configuration vulnerability

Mahsulot kodi to‘g‘ri bo‘lsa ham noto‘g‘ri sozlama zaiflik yaratadi.

Misollar:

• default parol;
• public storage;
• debug mode;
• ortiqcha permission;
• TLS validation o‘chiq;
• management port internetga ochiq;
• secret repositoryda.

Hardening configuration riskini kamaytiradi.

Design vulnerability

Architecture yoki business logic darajasidagi xato patchdan ko‘ra katta o‘zgarish talab qilishi mumkin.

Masalan:

• authorization modeli yo‘q;
• barcha tenant bir trust boundary’da;
• sensitive operationda verification yo‘q;
• single point of failure;
• secretni clientga berish.

Threat modeling design bosqichida bunday xatoni topadi.

Hardware vulnerability

CPU, chipset, firmware, device yoki physical interface’da vulnerability bo‘lishi mumkin.

Fix:

• firmware update;
• microcode;
• OS mitigation;
• hardware revision;
• qurilmani almashtirish

talab qilishi ehtimoli bor.

Hardware lifecycle software patchdan uzoqroq bo‘lishi mumkin.

Vulnerability lifecycle

Odatdagi jarayon:

1. weakness paydo bo‘ladi;
2. researcher yoki attacker topadi;
3. vendor xabardor qilinadi;
4. tahlil va triage;
5. patch yoki mitigation;
6. advisory;
7. deployment;
8. verification;
9. monitoring.

Zaiflik patch chiqarilishi bilan avtomatik yo‘qolmaydi; foydalanuvchi patchni o‘rnatishi kerak.

Discovery

Vulnerability quyidagi usullar bilan topiladi:

• code review;
• SAST;
• DAST;
• fuzzing;
• penetration test;
• bug bounty;
• incident tahlili;
• dependency scan;
• threat modeling;
• user report.

Har vosita barcha zaiflik turini topa olmaydi.

Severity

Technical severity ta’sir va exploitabilityni ifodalashi mumkin.

CVSS standard metriclardan foydalanadi.

Severity quyidagilar bilan birga ko‘riladi:

• exploit activity;
• asset importance;
• data;
• exposure;
• control;
• patch.

Patch

Patch vulnerable code yoki configurationni tuzatadi.

Patch jarayoni:

• fixed versionni aniqlash;
• test;
• rollback reja;
• staged deployment;
• compatibility;
• monitoring;
• verification.

Patch o‘rnatildi degan inventory ma’lumoti real file yoki service versiyasi bilan tekshiriladi.

Mitigation

Patch darhol bo‘lmasa vaqtinchalik mitigation qo‘llanadi:

• feature’ni o‘chirish;
• endpointni yopish;
• WAF rule;
• network allowlist;
• privilege kamaytirish;
• virtual patch;
• monitoring;
• isolation.

Mitigation root cause’ni tuzatmasligi mumkin.

Vulnerability management

Tashkilot:

• asset inventory;
• scanner;
• advisory feed;
• ownership;
• severity;
• SLA;
• exception;
• remediation;
• verification

jarayonlarini birlashtiradi.

Owner va deadline bo‘lmagan topilma uzoq vaqt ochiq qolishi mumkin.

False positive

Scanner zaiflik bor deb noto‘g‘ri signal berishi mumkin.

Masalan:

• backported patch;
• feature o‘chiq;
• version aniqlash xatosi;
• unreachable code;
• test package.

False positive tekshiriladi, lekin dalilsiz yopilmaydi.

Asset inventory

Zaiflikni boshqarish uchun qaysi product, version va component qayerda ishlatilayotgani ma’lum bo‘lishi kerak. Inventory bo‘lmasa advisory chiqqanda affected hostlarni topish qiyin. Ephemeral container, cloud instance va developer dependencylar ham inventarga kiradi.

Remediation exception

Ba’zan patch compatibility yoki availability sabab belgilangan muddatda o‘rnatilmaydi. Bunday exception:

• risk owner;
• sabab;
• compensating control;
• expiration;
• qayta review

bilan yoziladi. “Patch qilib bo‘lmaydi” doimiy yopish sababi emas.

Verification

Topilma fixed deb yopilishidan oldin real mitigation tekshiriladi. Faqat ticketda “done” yozilishi yetarli emas. Version, configuration, endpoint va exploit condition qayta test qilinadi. Regression keyingi release’da zaiflikni qaytarmasligi uchun test qo‘shiladi.

Ownership

Har topilma uchun system owner va remediation owner belgilanadi. Security jamoasi riskni tushuntirishi mumkin, ammo product jamoasi code va deploymentni tuzatadi. Owner noaniq bo‘lsa ticket jamoalar orasida ko‘chib, zaiflik ochiq qoladi.

Root cause

Bir xil zaiflik turli endpointlarda takrorlansa faqat individual line’larni patch qilish yetarli emas. Framework helper, shared library yoki development standarddagi root cause topiladi. Central fix kelajakdagi shu sinf xatolarini kamaytiradi.

Bog‘liq tushunchalar

Security vulnerability, Weakness, Threat, Risk, Exploit, Exposure, CVE, CVSS, Patch, Mitigation, Vulnerability management