CyberSecurity terminləri

Threat modelling, identity və access, application security, detection və response ilə bağlı terminlər.

Bu fəsildə: Allowlist · API key · Assume breach · Attack surface · Attack tree · Audit log · Authentication · Authorization · Availability · Blast radius · Broken function level authorization · Broken object property level authorization · Broken object-level authorization · CIA triad · Confidentiality · CORS · Credential · CSPM · Data flow diagram · Data minimisation · Data poisoning · Defence in depth · Encryption · Envelope encryption · Excessive agency · Hardening · Hash · Improper output handling · Incident response · Integrity · JWT · Key rotation · Lateral movement · Least privilege · MAC · Mass assignment · MFA · mTLS · OAuth 2.0 · OpenID Connect · Phishing · Policy-as-code · Ransomware · RBAC · Sandbox · Secret · Security misconfiguration · Shadow API · Shared responsibility model · SQL injection · SSRF · STRIDE · Supply chain · System prompt leakage · Threat actor · Threat model · Timing attack · TLS · Trust boundary · XSS · Zero trust

---

Allowlist

İcazə verilən dəyərlərin, ünvanların və ya əməliyyatların açıq siyahısı; siyahıda olmayan hər şey default olaraq rədd edilir.

Allowlist "nəyə icazə var?" sualına açıq cavab verən siyahıdır: icazə verilən IP range-ləri, domain-lər, input format-ları, alqoritmlər və ya tool-lar. Siyahıda olmayan hər şey rədd edilir. Onun əksi olan denylist isə yalnız məlum pis şeyləri bloklayır və qalan hər şeyi buraxır.

Fərq kiçik görünür, amma nəticəsi böyükdür. Denylist attacker-in ağlına gələ biləcək hər variantı əvvəlcədən təxmin etməyinizi tələb edir; bu, demək olar ki, həmişə nəyisə qaçırır. Allowlist isə düzgün input-un necə göründüyünü bir dəfə müəyyən edir və bilinməyəni avtomatik olaraq kənarda saxlayır. Bu, default deny prinsipinin konkret tətbiqidir.

Praktikada nümunələr:

• SSRF-ə qarşı application yalnız konkret xarici host-lara request göndərə bilir.
• JWT signature-i yalnız icazə verilən alqoritmlərlə validate olunur.
• Input validation tip, uzunluq və format üçün dəqiq qaydalarla aparılır.
• Agent-ə tapşırığa uyğun tool allowlist-i verilir: customer support agent-inə shell lazım deyil.

Trade-off: allowlist-i maintain etmək lazımdır. Yeni qanuni istifadə halı yarananda siyahı yenilənməlidir, əks halda istifadəçilər bloklanır və komanda "müvəqqəti" olaraq hər şeyi açır. Ən çox rast gəlinən səhv də budur: wildcard-larla genişləndirilmiş, faktiki olaraq heç nəyi məhdudlaşdırmayan allowlist.

Əlaqəli terminlər: Least privilege, SSRF, Attack surface, SQL injection

API key

API-ni çağıran application-ı identify edən uzunömürlü secret; istifadəçini identify etmir və tək başına authorization üçün kifayət deyil.

API key adətən header-də göndərilən random string-dir. O, "hansı client çağırır?" sualına cavab verir və quota, billing və usage tracking üçün faydalıdır.

Onun zəif tərəfləri strukturdan gəlir:

• Uzunömürlüdür və nadir hallarda rotate olunur.
• Çox vaxt scope-suzdur: key-in sahibi hər şeyi edə bilir.
• Mobil app-lərdə, frontend kodunda və public repository-lərdə asanlıqla leak olur. Client-ə göndərilən key secret deyil.
• İstifadəçinin kim olduğunu bildirmir, ona görə istifadəçi data-sına access qərarını onun əsasında vermək olmaz.

İstifadəçinin adından hərəkət edən API-lər üçün qısaömürlü, scope-lu və revoke edilə bilən OAuth 2.0 access token-ləri düzgün seçimdir. API key-ləri istifadə edirsinizsə, onları secret kimi saxlayın, hər key-ə minimal scope verin, server-də constant-time müqayisə edin, avtomatik rotation qurun və leak olunmuş key-ləri secret scanning ilə axtarın.

Əlaqəli terminlər: Secret, Credential, Authentication, Least privilege

Assume breach

Sistemi attacker-in artıq içəridə olduğunu fərz edərək layihələndirmək prinsipi: segment-lərə bölmək, monitor etmək və lateral movement-i bahalı etmək.

Assume breach perimeter-in nə vaxtsa keçiləcəyini qəbul edən düşüncə tərzidir. Sual "attacker içəri girə bilərmi?" deyil, "içəri girəndə nəyə çata bilər və biz bunu nə qədər tez görəcəyik?" olur.

Bu prinsip vacibdir, çünki compromise-dan detection-a qədər keçən vaxt sənaye hesabatlarında həftələr, bəzən aylarla ölçülür. Bu müddətdə attacker lateral movement edir, privilege toplayır və data-nı exfiltrate edir. Əgər sistem yalnız xarici divara etibar edirsə, içəridə heç nə onu dayandırmır.

Praktikada assume breach bunları tələb edir:

• Şəbəkəni və service-ləri segment-lərə bölmək, bir compromise olunmuş host-un hər şeyə çatmaması üçün.
• Daxili trafikə də authentication və authorization tətbiq etmək, yəni zero trust istiqamətində hərəkət.
• Credential-ları qısaömürlü etmək və scope-unu məhdudlaşdırmaq.
• Attacker-in dəyişdirə bilmədiyi yerdə audit log saxlamaq.
• Backup-ları offline və ya immutable saxlamaq.

Konkret məşq: "attacker-in əlində developer-in laptop-u var" ssenarisini götürün və o laptop-dan hansı secret-lərə, repository-lərə və production sistemlərinə çatmaq mümkün olduğunu sadalayın. Siyahı adətən gözləniləndən uzun çıxır.

Ümumi səhv bu prinsipi paranoya kimi başa düşməkdir. Məqsəd hər şeyi bağlamaq deyil, blast radius-u məhdudlaşdırmaq və detection üçün siqnal yaratmaqdır.

Əlaqəli terminlər: Lateral movement, Blast radius, Zero trust, Defence in depth, Incident response

Attack surface

Attacker-in sistemə təzyiq göstərə biləcəyi bütün nöqtələrin cəmi: açıq port-lar, endpoint-lər, dependency-lər, feature-lər, input yolları.

Attack surface sistemin xaricdən toxunula bilən bütün hissələridir: hər açıq port, hər API endpoint-i, hər file upload forması, hər dependency, hər admin panel, hər credential, hətta hər əməkdaşın e-poçt qutusu. Bunların hər biri attacker üçün potensial giriş nöqtəsidir.

Attack surface böyüdükcə qorunmalı olan yerlərin sayı artır, amma defender-in büdcəsi və diqqəti artmır. Buna görə də ən effektiv control-lardan biri sadəcə lazım olmayanı silməkdir. İstifadə olunmayan endpoint-in vulnerability-si heç vaxt problem yaratmayacaq, çünki o mövcud deyil.

Praktikada attack surface-i azaltmaq bu cür görünür:

• Debug endpoint-lərini və köhnə API versiyalarını production-dan çıxarmaq.
• Daxili service-ləri public şəbəkədən gizlətmək.
• Az transitive dependency-si olan library-lərə üstünlük vermək.
• Feature-ləri default olaraq söndürülmüş ship etmək.

Nümunə: köhnə mobil app versiyası üçün saxlanan, artıq heç kimin test etmədiyi v1 API-si. Onun authorization check-ləri v2-dən geri qalır və attacker məhz ona hücum edir.

AI sistemləri yeni attack surface əlavə edir: modelin oxuduğu hər mətn prompt injection üçün kanal ola bilər. Ümumi səhv attack surface-i yalnız şəbəkə səviyyəsində düşünməkdir; insanlar, CI pipeline-ları və supply chain də onun hissəsidir.

Əlaqəli terminlər: Trust boundary, Threat model, Supply chain, Prompt injection

Attack tree

Root-u attacker-in məqsədi olan və aşağıya doğru ona çatmağın yollarını budaqlandıran threat modelling texnikası; leaf-lər konkret attack-lərdir.

Attack tree attacker-in məqsədindən geriyə doğru işləyən diaqramdır. Root düyün məqsəddir, məsələn, "başqa müştərinin invoice-larını oxumaq". Uşaq düyünlər bu məqsədə çatmağın alternativ yollarıdır, nəvə düyünlər həmin yolların hər birinə necə çatmağı göstərir, leaf-lər isə konkret, icra oluna bilən attack-lərdir.

Nümunə ağac:

• Başqa müştərinin invoice-larını oxumaq
  • API-də object-level authorization boşluğundan istifadə etmək
  • Support əməkdaşının account-unu phishing ilə ələ keçirmək
  • Backup-ları saxlayan cloud storage-ə çatmaq
    • Leak olmuş access key tapmaq
    • Səhv konfiqurasiya olunmuş public bucket

Hər leaf ehtimal və xərclə qeyd olunur. Bu, hansı budaqların ucuz və real olduğunu göstərir və control-ları prioritetləşdirməyə kömək edir.

Attack tree-nin dəyəri STRIDE-ı tamamlamasındadır. STRIDE data flow diagram-dakı elementləri bir-bir gəzir və hər biri üçün threat kateqoriyalarını yoxlayır. Attack tree isə bir neçə kiçik zəifliyi zəncirləyən yolları üzə çıxarır, məsələn, məlumat sızdıran error mesajı plus zəif rate limit plus təxmin edilə bilən ID.

Trade-off: attack tree qurmaq vaxt aparır və hər şey üçün lazım deyil. Onu yüksək dəyərli hədəflər üçün saxlayın. Ümumi səhv ağacı yalnız texniki attack-lərlə doldurmaq və social engineering budaqlarını unutmaqdır.

Əlaqəli terminlər: Threat model, STRIDE, Data flow diagram, Threat actor

Audit log

Kimin nə vaxt, haradan, nə etdiyini və nəticəsini qeydə alan, actor-un özünün dəyişdirə bilmədiyi yerdə saxlanan hadisələr jurnalı.

Audit log authentication, authorization və accounting üçlüyünün sonuncu hissəsidir: hərəkətlərin sonradan konkret actor-a qədər izlənilə bilməsi. Adi application log-larından fərqli olaraq, onun məqsədi debugging deyil, sübut və araşdırmadır.

Hər qeyd ən azı bunları daşımalıdır: kim (istifadəçi və ya service identity-si), nə (hərəkət və target), nə vaxt (sinxronlaşdırılmış saatla timestamp), haradan (IP, device, session) və nəticə (uğurlu, rədd edildi, error).

Nəyi log etmək lazımdır:

• Bütün authentication hadisələri, o cümlədən uğursuzluqlar və MFA prompt-ları.
• Hər rədd edilmiş authorization qərarı.
• Privileged hərəkətlər: role dəyişiklikləri, permission grant-ları, data export-ları.
• AI sistemlərində agent-in hər tool call-u, arqumentləri və nəticəsi ilə birlikdə.

Ən vacib tələb budur ki, log-lar actor-un çata və ya dəyişə bilmədiyi mərkəzi store-a getsin. Admin hüquqları olan attacker öz izlərini silə bilirsə, audit log faydasızdır. Separation of duties prinsipi də burada tətbiq olunur: deploy edən şəxs audit log-larını dəyişə bilməməlidir.

Retention yavaş intrusion-u araşdırmağa kifayət edəcək qədər uzun olmalıdır, adətən bir il. Ümumi səhvlər: log-lara secret və ya password yazmaq, saatları sinxronlaşdırmamaq və heç kimin oxumadığı log-ları toplamaq.

Əlaqəli terminlər: Incident response, Authorization, Authentication, Integrity

Authentication

"Sən kimsən?" sualına cavab: istifadəçinin, device-ın və ya service-in iddia etdiyi identity-yə həqiqətən sahib olduğunun yoxlanması.

Authentication identity-nin sübutudur. İstifadəçi və ya service "mən filankəsəm" deyir və sistem bunu bir və ya bir neçə factor ilə yoxlayır: bildiyiniz bir şey (password), sahib olduğunuz bir şey (telefon, hardware key) və ya olduğunuz bir şey (biometric).

Authentication authorization ilə qarışdırılmamalıdır. Birincisi kim olduğunuzu, ikincisi nə etməyə icazəniz olduğunu müəyyən edir. "Login olub" check-ini "icazəsi var" kimi qəbul edən sistemlər elevation-of-privilege bug-larının əsas mənbəyidir.

Praktikada güclü authentication bunları əhatə edir:

• Password-ləri Argon2id və ya bcrypt kimi yavaş hash ilə, hər biri üçün ayrıca salt ilə saxlamaq.
• Breach siyahılarında görünən password-ləri rədd etmək.
• MFA tətbiq etmək, mümkün olduqda passkey kimi phishing-resistant factor-larla.
• Cəhdləri rate limit etmək.
• Uğurlu login-dən sonra session token-ini password kimi qorumaq: random, qısaömürlü, yalnız TLS üzərindən.

Service-lər üçün authentication workload identity ilə edilir: platform workload-a zəmanət verir və qısaömürlü credential-lar avtomatik verilir.

Ən çox rast gəlinən səhvlər: dövri password rotation-u məcbur etmək (proqnozlaşdırıla bilən variasiyalar yaradır), daxili service-lər arasında authentication-u "onsuz da içəridədir" deyərək atlamaq, və password reset axınını əsas login-dən zəif qoymaq.

Əlaqəli terminlər: Authorization, MFA, Credential, Phishing, Zero trust

Authorization

"Sənə nə etməyə icazə var?" sualına cavab: authenticate olmuş actor-un konkret resource üzərində konkret hərəkəti edə bilib-bilməməsinin yoxlanması.

Authorization authentication-dan sonra gəlir. Sistem artıq kiminlə danışdığını bilir; indi isə bu actor-un məhz bu resource üzərində məhz bu hərəkəti etməyə hüququ olub-olmadığına qərar verir.

Bunun üçün bir neçə model var: RBAC (role-lar və onlara bağlı permission-lar), ABAC (istifadəçinin, resource-un və kontekstin attribute-ları) və ReBAC (graph-dakı əlaqələr, məsələn, "sənədin owner-i"). Sistemlərin əksəriyyəti RBAC ilə başlamalıdır.

Əsas prinsiplər:

• Default deny. Heç bir qayda uyğun gəlmirsə, access yoxdur.
• Hər layer-də yoxlamaq. UI düyməni gizlədir, amma API yenə yoxlayır, database isə mümkün olan yerdə row-level policy tətbiq edir.
• Mərkəzləşdirmək. Authorization məntiqi bir funksiyada və ya policy engine-də yaşayır, codebase-ə səpələnmiş if-lərdə yox.
• Fail securely. Check exception atanda access rədd edilir.

Konkret nümunə: GET /invoices/123 request-i. Authentication istifadəçinin kim olduğunu təsdiqləyir. Authorization isə 123 nömrəli invoice-un bu istifadəçinin tenant-ına aid olub-olmadığını yoxlamalıdır. Bu ikinci addım unudulanda broken object-level authorization yaranır, real assessment-lərdə ən çox rast gəlinən kritik tapıntı.

Trade-off: incə dənəli authorization daha dəqiqdir, amma mühakimə etmək və audit etmək çətinləşir. Ümumi səhv də yalnız UI səviyyəsində yoxlamaqdır.

Əlaqəli terminlər: Authentication, RBAC, Least privilege, Broken object-level authorization

Availability

CIA triad-ın üçüncü xassəsi: sistemlərin və data-nın lazım olan anda qanuni istifadəçilər üçün istifadəyə yararlı olması.

Availability sistemin lazım olanda işləməsi deməkdir. Architecture kontekstində o, uptime faizi ilə ölçülən quality attribute-dur; security kontekstində isə attacker-in qəsdən pozmağa çalışdığı xassədir.

Availability-yə attack-lərin əsas formaları:

• Denial of service. Sistemi request-lərlə və ya bahalı əməliyyatlarla tükəndirmək. STRIDE-dakı D hərfi məhz budur.
• Ransomware. Data-nı encrypt edərək əlçatmaz etmək. Klassik ransomware birbaşa availability-yə vurur.
• Resource tükənməsi. Böyük upload-lar, dərin recursion, məhdudiyyətsiz query-lər, zərərli parser input-ları.

Müdafiə həm security, həm də resilience mühəndisliyidir: rate limiting, request və upload size limit-ləri, timeout-lar, kifayət qədər capacity, kritik service-lər üçün redundancy və ən əsası test edilmiş, offline və ya immutable backup-lar. Ransomware-dən recovery vaxtı demək olar ki, tamamilə backup-ların salamat və restore edilə bilən olmasından asılıdır.

Maraqlı gərginlik: bəzi security control-ları availability-ni azalda bilər. Login cəhdlərini lock out etmək brute force-u dayandırır, amma attacker qəsdən səhv password-lər göndərərək qanuni istifadəçini kilidləyə bilər. Buna görə lockout həm account, həm də mənbə üzrə düşünülməlidir.

Ümumi səhv availability-ni yalnız ops komandasının məsələsi saymaq və degraded mode-ları, yəni sistemlər dayananda biznesin necə işləyəcəyini planlaşdırmamaqdır.

Əlaqəli terminlər: CIA triad, Confidentiality, Integrity, Ransomware, Quality attribute

Blast radius

Bir komponent, account və ya credential compromise olunanda zərərin yayıla biləcəyi sahənin ölçüsü: attacker-in oradan nələrə çata biləcəyi.

Blast radius "bu şey compromise olunsa, nə itirərik?" sualının cavabıdır. Bir service account-un bütün database-lərə write access-i varsa, onun blast radius-u bütün data-dır. Yalnız bir cədvəli oxuya bilirsə, zərər həmin cədvəllə məhdudlaşır.

Bu anlayış security-ni ehtimaldan təsirə yönəldir. Hər compromise-ın qarşısını almaq mümkün deyil, amma hər compromise-ın nəticəsini kiçik saxlamaq mümkündür. Buna görə də least privilege, segmentation və assume breach prinsiplərinin hamısı əslində blast radius-u azaltmaq haqqındadır.

Blast radius-u kiçiltməyin praktik yolları:

• Hər service-ə ayrıca, scope-u məhdud credential vermək; shared admin key-lərdən qaçmaq.
• Şəbəkəni və cloud account-larını mühitlərə və tenant-lara görə ayırmaq.
• Uzunömürlü token-lər əvəzinə qısaömürlü credential-lar istifadə etmək.
• CI runner-lərinin çata bildiklərini məhdudlaşdırmaq.
• AI agent-lərinə yalnız tapşırığa lazım olan tool-ları vermək.

Nümunə: reporting job-u üçün yaradılmış credential leak olur. Əgər o yalnız read-only replica-ya çıxış verirsə, incident ciddi, amma idarə ediləndir. Əgər production-un admin role-u idisə, şirkət üçün böhrandır.

Ümumi səhv rahatlıq üçün bir credential-ı bir neçə sistemdə paylaşmaq və ya "müvəqqəti" verilmiş geniş icazələri heç vaxt geri almamaqdır.

Əlaqəli terminlər: Least privilege, Assume breach, Lateral movement, Credential

Broken function level authorization

Adi istifadəçinin admin və ya başqa privileged endpoint-ləri çağıra bildiyi vulnerability; server əməliyyata icazəni yoxlamır.

Broken function level authorization OWASP API Security Top 10 2023-də API5-dir. BOLA "bu obyektə çata bilərsənmi?" sualını unudur, bu bug isə "bu əməliyyatı edə bilərsənmi?" sualını.

Tipik ssenarilər:

• Admin endpoint-ləri /api/admin/... prefix-indədir və developer-lər onları "heç kim bilmir" deyə check-siz buraxıb.
• GET /api/users/42 hər kəs üçün işləyir, amma eyni path-ə DELETE və ya PUT göndərəndə də check olmur.
• UI-da düymə yalnız admin-ə göstərilir və bu, yeganə qoruma sayılır.

Attacker API sənədlərindən, mobil app-in kodundan və ya sadəcə URL pattern-lərini təxmin etməklə bu endpoint-ləri tapır.

Həll default deny-dir: hər route üçün tələb olunan role və ya permission açıq şəkildə elan olunur, elan olunmayan route deploy olunmur, və authorization matrisi (hər endpoint × hər role) avtomatik test kimi CI-də işləyir.

Əlaqəli terminlər: Broken object-level authorization, RBAC, Authorization, Least privilege

Broken object property level authorization

İstifadəçinin obyektə access-i olsa da, onun görməməli olduğu field-ləri oxuya və ya dəyişməməli olduğu field-ləri yaza bildiyi API vulnerability-si.

Bu risk OWASP API Security Top 10 2023-də API3-dür və əvvəlki siyahıdakı iki ayrı problemi birləşdirir: excessive data exposure və mass assignment. Hər ikisində sual eynidir: "bu istifadəçi bu obyektin bu field-inə çata bilərmi?"

Excessive data exposure oxuma tərəfidir. Endpoint database obyektini olduğu kimi serialize edir və cavabda email, telefon, password hash, daxili flag-lar qaytarır. Frontend onları göstərmir, ona görə developer problemi görmür, amma attacker response-u birbaşa oxuyur. Filtering-i client-ə həvalə etmək authorization deyil.

Mass assignment yazma tərəfidir: istifadəçi request body-yə gözlənilməyən field əlavə edir və server onu obyektə yazır.

Müdafiə hər iki istiqamətdə eynidir: hər endpoint üçün oxuna bilən və yazıla bilən field-lərin açıq allowlist-i, response schema-sına qarşı test-lər və role-dan asılı olaraq fərqli field dəstləri qaytaran ayrıca serializer-lər.

Əlaqəli terminlər: Mass assignment, Broken object-level authorization, Authorization, Least privilege

Broken object-level authorization

API-nin istifadəçinin login olduğunu yoxlayıb, amma məhz bu obyektə access hüququnu yoxlamadığı vulnerability; ID-ni dəyişməklə başqasının data-sı görünür.

Broken object-level authorization, qısaca BOLA, illərdir OWASP API Security siyahısının başında olan bug sinfidir. Ssenari sadədir: GET /api/orders/1001 request-i login olmuş istifadəçinin öz sifarişini qaytarır. İstifadəçi URL-də 1001-i 1002-yə dəyişir və başqa müştərinin sifarişini görür. Server yalnız "bu istifadəçi authenticate olubmu?" sualını verib, "bu sifariş bu istifadəçiyə aiddirmi?" sualını yox.

Bu bug çox yayılıb, çünki hər endpoint-də, hər yeni feature-də check-i əl ilə əlavə etmək lazım gəlir və bir dəfə unutmaq kifayətdir. Ardıcıl ID-lər onu daha da asanlaşdırır, amma UUID istifadə etmək həll deyil, yalnız gizlətmədir.

Həll strukturdadır:

• Hər data access-i hərəkət edən istifadəçini və target obyekti qəbul edən mərkəzi funksiyadan keçir.
• Bu funksiyanı atlayan kod yolu yoxdur, ona görə check-i unutmaq mümkün olmur.
• Mümkün olan yerdə database row-level security tətbiq edir.
• Hər endpoint üçün "başqa istifadəçinin ID-si ilə request 403 və ya 404 qaytarır" test-i yazılır.

Oxşar bug function-level authorization-dur: adi istifadəçi admin endpoint-ini birbaşa çağıra bilir, çünki yalnız UI düyməni gizlədib.

Ümumi səhv authorization-u controller-lərə səpələnmiş if user.is_admin ifadələri ilə həll etməyə çalışmaqdır.

Əlaqəli terminlər: Authorization, RBAC, Threat model

CIA triad

Security-nin qoruduğu üç klassik xassə: confidentiality, integrity və availability. Hansı xassənin attack altında olduğunu bilmək uyğun control-u göstərir.

CIA triad security-nin nəyi qoruduğunu təsvir edən klassik çərçivədir:

• Confidentiality: data-nı yalnız icazəsi olanlar görür.
• Integrity: data və sistemlər yalnız icazəsi olanlar tərəfindən, icazə verilən üsullarla dəyişdirilir.
• Availability: sistemlər lazım olanda istifadəyə yararlıdır.

Praktikada iki əlavə onu daha faydalı edir: authenticity (kimin nə etdiyini və mesajın haradan gəldiyini yoxlaya bilmək) və non-repudiation, yəni accountability (hərəkətlərin sonradan konkret actor-a qədər izlənilə bilməsi).

Triad-ın əsas dəyəri diaqnostikdir. Hər threat bu xassələrdən birini pozur, və hansını pozduğunu bilmək müdafiəni istiqamətləndirir:

• Ransomware availability-yə, data leak hədəsi ilə isə confidentiality-yə vurur.
• Fraud integrity-yə vurur.
• Credential oğurluğu authenticity-yə vurur.

STRIDE də bu xassələrə map olunur: information disclosure confidentiality-ni, tampering integrity-ni, denial of service availability-ni pozur.

Trade-off-lar burada da var. Maksimum confidentiality üçün hər şeyi bağlamaq availability-ni azaldır; maksimum availability üçün hər yerdə cache və replica saxlamaq data-nın daha çox yerdə görünməsi deməkdir. Ümumi səhv triad-ı checklist kimi bir dəfə doldurub kənara qoymaqdır; o, hər yeni feature və hər threat üçün təkrar verilməli sualdır.

Əlaqəli terminlər: Confidentiality, Integrity, Availability, STRIDE, Trade-off

Confidentiality

CIA triad-ın birinci xassəsi: data-nı yalnız onu görməyə icazəsi olan insanların və service-lərin görə bilməsi.

Confidentiality məlumatın icazəsiz şəxslərə açılmamasıdır. STRIDE-da onu pozan threat information disclosure adlanır: kimsə görməməli olduğu data-nı görür.

Confidentiality yalnız encryption məsələsi deyil. O, bir neçə control-un birlikdə işləməsindən yaranır:

• Access control. Authentication və authorization kimin nəyi görə biləcəyini müəyyən edir.
• Encryption. Şəbəkədə TLS, diskdə və backup-larda at-rest encryption.
• Data minimisation. Saxlamadığınız data leak ola bilməz.
• Output nəzarəti. API response-larında lazım olandan artıq field qaytarmamaq, error mesajlarında daxili təfərrüatları göstərməmək.

Real həyatda confidentiality pozuntuları çox vaxt hiyləgər kriptoqrafik attack-lərdən yox, sadə səhvlərdən yaranır: public qalmış cloud storage bucket, over-fetching edən API, log-lara yazılmış token-lər, həddindən artıq ətraflı stack trace, və ya broken object-level authorization.

Nümunə: mobil app üçün istifadəçi profili endpoint-i bütün user obyektini qaytarır, o cümlədən password hash-ini və daxili qeydləri. UI onları göstərmir, amma network tab-da hamısı görünür.

Müasir ransomware qrupları confidentiality-yə də vurur: data-nı encrypt etməzdən əvvəl kopyalayır və ödəniş olmasa leak etməklə hədələyir. Buna görə də yalnız backup-lar artıq kifayət etmir.

Əlaqəli terminlər: CIA triad, Encryption, Authorization, Integrity

CORS

Server-in brauzerə hansı başqa origin-lərdən gələn JavaScript-in onun cavablarını oxuya biləcəyini bildirdiyi mexanizm; authentication və ya authorization deyil.

Brauzerin same-origin policy-si bir saytdakı script-in başqa origin-ə request göndərib cavabı oxumasına icazə vermir. CORS bu qaydanı kontrollu şəkildə yumşaldır: server Access-Control-Allow-Origin və əlaqəli header-lərlə "bu origin-ə etibar edirəm" deyir.

Ən çox rast gəlinən yanlış anlama CORS-u qoruma mexanizmi saymaqdır. curl, server-side script və mobil app CORS-a məhəl qoymur. CORS yalnız brauzerdəki digər saytların istifadəçinin adından nə edə biləcəyini məhdudlaşdırır.

Təhlükəli konfiqurasiyalar:

• Request-in Origin header-ini olduğu kimi geri qaytarmaq və eyni zamanda Access-Control-Allow-Credentials: true göndərmək. Bu halda istənilən sayt istifadəçinin cookie-ləri ilə API-ni çağırıb cavabı oxuyur.
• null origin-ə icazə vermək.
• Origin-i zəif regex və ya "ilə bitir" check-i ilə yoxlamaq: evil-example.com da example.com ilə bitir.

Düzgün yanaşma dəqiq origin allowlist-i və credential-lı request-lərə yalnız həqiqətən lazım olan origin-lər üçün icazədir.

Əlaqəli terminlər: Allowlist, XSS, Authorization

Credential

Identity-ni sübut etmək üçün istifadə olunan sirr: password, API key, token, private key, sertifikat və ya session cookie.

Credential sistemə "mən bu identity-yəm" demək üçün təqdim olunan hər şeydir: istifadəçi password-ü, API key, OAuth token, SSH private key, cloud access key, session cookie. Kimin əlindədirsə, sistem üçün o, həmin identity-dir.

Breach-lərin əksəriyyəti hiyləgər exploit-lə yox, credential ilə başlayır: phishing-lə ələ keçirilmiş, başqa saytda leak olub təkrar istifadə edilmiş, təxmin edilmiş və ya config faylında, repository-də qalmış. Attacker etibarlı credential əldə etdikdən sonra heç nəyi sındırmağa ehtiyac duymur, sadəcə login edir, və onun trafiki qanuni istifadəçininkindən fərqlənmir.

Credential-ları idarə etməyin əsas qaydaları:

• İnsanlar üçün MFA, xüsusilə phishing-resistant factor-lar.
• Machine credential-ları üçün secrets manager və runtime-da inject etmək; kodda və config-də heç nə.
• Qısaömürlü credential-lara üstünlük vermək, ideal halda workload identity ilə avtomatik verilənlərə.
• Scope-u minimuma endirmək: reporting job-unun write access-ə ehtiyacı yoxdur.
• Avtomatik rotation; heç vaxt rotate edilməmiş credential rotate edilə bilməyən credential-dır.

Incident zamanı eradication mərhələsi hər oğurlanmış credential-ın rotate olunmasını tələb edir. Bir dənəsini qaçırmaq attacker-in geri qayıtmasının ən tipik yoludur.

Ümumi səhv machine credential-larının inventarını aparmamaqdır: çox vaxt onlar insanlardan sayca çoxdur və heç kim ən köhnəsinin nə vaxt yaradıldığını bilmir.

Əlaqəli terminlər: Secret, Authentication, MFA, Phishing, Blast radius

CSPM

Cloud account-ları davamlı scan edərək misconfiguration-ları tapan tool kateqoriyası: public resource-lar, açıq port-lar, encryption-sız storage, geniş IAM policy-lər.

Cloud security posture management cloud mühitinin faktiki vəziyyətini təhlükəsizlik qaydalarına qarşı davamlı yoxlayır. Provider API-ləri vasitəsilə bütün account-ları və region-ları oxuyur və tapıntıları risk-ə görə sıralayır.

Tipik tapıntılar:

• Public storage bucket-lər və snapshot-lar.
• İnternet-ə açıq management port-ları.
• Audit logging-in söndürüldüyü region-lar.
• Wildcard permission-lı və ya istifadə olunmayan role-lar.
• Uzun müddət rotate olunmamış access key-lər.

CSPM policy-as-code-u tamamlayır: policy-as-code pis dəyişikliyin qarşısını alır, CSPM isə artıq mövcud olan, console-dan edilmiş və ya köhnə resource-ları tapır.

Ümumi səhv tool-u quraşdırıb tapıntılara baxmamaqdır. Minlərlə tapıntılı dashboard heç kimə kömək etmir. Hər tapıntı kateqoriyası üçün owner təyin edin, kritikləri alert kimi route edin və sayın zamanla azaldığını ölçün.

Əlaqəli terminlər: Security misconfiguration, Policy-as-code, Shared responsibility model, Audit log

Data flow diagram

Threat modelling-in başlanğıc nöqtəsi: external entity-ləri, process-ləri, data store-ları, data flow-ları və trust boundary-ləri göstərən diaqram.

Data flow diagram threat modelling-in "nə qururuq?" sualına cavab verir. O, adi architecture diaqramından fərqlidir: komponentlərin necə deploy olunduğunu yox, data-nın haradan haraya hərəkət etdiyini və trust səviyyəsinin harada dəyişdiyini göstərir.

Diaqramın beş elementi var:

• External entity-lər: istifadəçilər, third-party service-lər, nəzarət etmədiyiniz digər sistemlər.
• Process-lər: sizin service-ləriniz və komponentləriniz.
• Data store-lar: database-lər, cache-lər, queue-lar, file storage.
• Data flow-lar: nəyin hara getdiyini göstərən oxlar.
• Trust boundary-lər: trust səviyyəsinin dəyişdiyi yerlərdə nöqtəli xətlər.

Ən vacib hissə trust boundary-ləri keçən oxlardır. Hər belə ox STRIDE ilə yoxlanılmalı yerdir.

Nümunə: sadə SaaS üçün diaqramda browser (external entity), API gateway, application service, PostgreSQL, S3 bucket və ödəniş provider-i olur. İnternet ilə gateway arasında, service ilə database arasında və service ilə ödəniş provider-i arasında boundary-lər çəkilir. Multi-tenant sistemdə tenant-lar arasında da görünməz boundary var.

Diaqramı bir səhifəyə sığacaq qədər kiçik saxlayın; sığmırsa, subsystem-i ayrıca model edin. Ümumi səhvlər: diaqramı bir dəfə çəkib yeniləməmək, async flow-ları (queue-lar, webhook-lar) unutmaq və admin tool-ları kimi daxili yolları göstərməmək.

Əlaqəli terminlər: Threat model, Trust boundary, STRIDE, Attack tree

Data minimisation

Yalnız konkret məqsəd üçün lazım olan data-nı toplamaq, lazım olan müddət saxlamaq və lazım olan yerə ötürmək prinsipi.

Data minimisation ən ucuz və ən effektiv data protection control-udur: sizdə olmayan data breach-də sızmır, log-a düşmür, backup-da qalmır və subpoena ilə tələb olunmur.

Prinsip üç ölçüdə tətbiq olunur:

• Toplama. Yalnız feature-in həqiqətən istifadə etdiyi field-lər toplanır. Doğum tarixi əvəzinə "18 yaşdan yuxarı" flag-i, kart nömrəsi əvəzinə payment provider-in token-i.
• Saxlama. Hər data növünün retention müddəti olur və müddəti bitəndə avtomatik silinir, backup-lar da daxil olmaqla.
• Ötürmə. API cavabları, log-lar, analitika export-ları və üçüncü tərəf integration-ları yalnız lazım olan field-ləri daşıyır.

Minimisation həm də hüquqi tələbdir: GDPR kimi data protection qanunları onu açıq şəkildə prinsip kimi müəyyən edir.

Ümumi səhv "nə vaxtsa lazım ola bilər" düşüncəsi ilə hər şeyi saxlamaqdır. Data-nın dəyəri gələcəkdə şübhəlidir, riski isə bu gündən realdır. Digər səhv bütün obyekti serialize edən API endpoint-ləridir: database-də saxlamaq lazım olan field cavabda olmamalıdır.

Əlaqəli terminlər: Confidentiality, Blast radius, Audit log, Attack surface

Data poisoning

Model-in öyrəndiyi və ya istifadə etdiyi data-nın (training, fine-tuning, RAG korpusu, agent memory-si) qəsdən korlanaraq onun davranışının dəyişdirilməsi.

Data poisoning OWASP Top 10 for LLM Applications siyahısında LLM04-dür. Attacker model-ə birbaşa toxunmur; onun öyrəndiyi və ya oxuduğu mənbəni dəyişir.

Hücumun bir neçə nöqtəsi var:

• Training və fine-tuning data-sı. Zəhərlənmiş nümunələr backdoor yaradır: model adi input-larda normal davranır, yalnız müəyyən trigger ifadədə dəyişir. Bunu evaluation ilə tutmaq çətindir.
• RAG korpusu. Index-ə daxil olan wiki səhifəsinə, ticket-ə və ya public veb səhifəyə yaza bilən hər kəs model-in cavablarına təsir edə bilər, həm yanlış məlumatla, həm də indirect prompt injection ilə.
• Agent memory-si. Bir session-da injection ilə memory-yə yazılmış qeyd gələcək session-larda təlimat kimi işləyir və orijinal hücum çoxdan bitəndən sonra da təsir edir.

Müdafiə tədbirləri: model və dataset provenance-ını qeyd etmək (mənbə, versiya, checksum), RAG-a nəyin daxil olduğunu və kimin onu dəyişə biləcəyini bilmək, memory yazılarını məhdudlaşdırmaq və mənbəyini qeyd etmək, memory-ni istifadəçiyə görünən və silinə bilən etmək.

Ümumi səhv: poisoning-i yalnız böyük model-ləri öyrədən komandaların problemi saymaq. RAG və memory istifadə edən hər application-ın yazıla bilən data mənbəyi var.

Əlaqəli terminlər: Supply chain, Retrieval-augmented generation, Fine-tuning, Prompt injection, Integrity

Defence in depth

Heç bir control-un tək başına dayanacağına etibar etməyən prinsip: bir neçə müstəqil müdafiə layer-i, hər biri əvvəlkinin artıq keçildiyini fərz edir.

Defence in depth security-ni bir divar kimi deyil, ardıcıl layer-lər kimi qurmaqdır. Firewall, sonra authentication, sonra authorization, sonra input validation, sonra monitoring. Hər layer özündən əvvəlkinin artıq sıradan çıxdığını fərz edir.

Bu prinsip vacibdir, çünki hər control nə vaxtsa uğursuz olur: konfiqurasiya səhvi, yeni zero-day, phishing ilə ələ keçirilmiş password. Tək bir control-a güvənən sistemdə bu uğursuzluq birbaşa breach deməkdir. Layer-li sistemdə isə attacker növbəti maneə ilə qarşılaşır və hər maneə detection üçün yeni şans yaradır.

Konkret nümunə, SQL injection-a qarşı:

• Kod parameterised query-lərdən istifadə edir (əsas müdafiə).
• Input boundary-də allowlist ilə validate olunur.
• Application-ın database user-i yalnız lazım olan cədvəllərə access-ə malikdir.
• Qeyri-adi query pattern-ləri üçün monitoring var.

Birinci layer bir yerdə unudulsa belə, qalanları zərəri məhdudlaşdırır.

Vacib nüans: layer-lər həqiqətən müstəqil olmalıdır. Eyni credential ilə açılan üç layer əslində bir layer-dir. Eyni vendor-un eyni bug-ı olan iki məhsul da elə.

Trade-off: hər layer mürəkkəblik və xərc əlavə edir, mürəkkəblik isə vulnerability-lərin gizləndiyi yerdir. Ümumi səhv layer-lərin sayını təhlükəsizliklə eyniləşdirmək və ya "WAF var, kodda validation lazım deyil" deyə düşünməkdir.

Əlaqəli terminlər: Least privilege, Zero trust, Assume breach, Trade-off

Encryption

Data-nı yalnız düzgün key-ə sahib olanın geri oxuya biləcəyi formaya çevirən geri çevrilə bilən kriptoqrafik əməliyyat; confidentiality-nin əsas aləti.

Encryption plaintext-i key vasitəsilə ciphertext-ə çevirir; key olmadan ciphertext-dən məna çıxarmaq praktiki olaraq mümkün deyil. Hash-dən fərqli olaraq encryption geri çevrilə biləndir: düzgün key ilə data əvvəlki halına qaytarılır.

Praktikada iki əsas kontekst var:

• In transit. Şəbəkədə hərəkət edən data, adətən TLS ilə. Session token-ləri və cookie-lər yalnız TLS üzərindən ötürülməlidir.
• At rest. Disklərdə, database-lərdə, backup-larda və laptop-larda saxlanan data.

Encryption-un gücü tamamilə key management-dən asılıdır. Ən güclü alqoritm belə key public repository-dədirsə, heç nə ifadə etmir. Key-lər secrets manager və ya KMS-də saxlanılmalı, rotate edilməli, access-i log-lanmalıdır.

Əsas qaydalar:

• Öz kriptoqrafiyanızı yazmayın. Safe default-ları olan high-level library-lərdən (libsodium, dilin standart vetted library-si) istifadə edin.
• Hansı alqoritmlərin və mode-ların deprecated olduğunu bilin.
• Password-ləri encrypt etməyin, onları yavaş hash ilə saxlayın.

Encryption authorization-u əvəz etmir. Disk encrypt olunub, amma application hər istifadəçiyə istənilən sətri decrypt edib qaytarırsa, data qorunmur.

Ümumi səhvlər: key-i encrypt olunmuş data-nın yanında saxlamaq, sərt kodlanmış IV və ya nonce istifadə etmək, və TLS sertifikat yoxlamasını "müvəqqəti" söndürüb unutmaq.

Əlaqəli terminlər: Confidentiality, Hash, Secret, Integrity

Envelope encryption

Data-nın öz data key-i ilə encrypt olunduğu, data key-in isə KMS-dəki master key ilə encrypt olunub data-nın yanında saxlandığı pattern.

Envelope encryption iki səviyyəli key strukturudur. Data key (data encryption key) faktiki data-nı lokal olaraq, sürətli symmetric authenticated encryption ilə encrypt edir. Master key (key encryption key) isə yalnız data key-i encrypt edir və KMS və ya HSM-i heç vaxt tərk etmir. Encrypt olunmuş data key ciphertext-in yanında saxlanılır.

Bu pattern bir neçə problemi birdən həll edir:

• Böyük data KMS-ə göndərilmir; KMS-ə yalnız kiçik data key-lər gedir.
• Database və ya backup oğurlansa da, master key olmadan data key-lər açılmır.
• Master key-ə access identity ilə idarə olunur və hər istifadəsi audit log-a düşür.
• Master key rotate olunanda bütün data-nı yenidən encrypt etmək lazım deyil; yalnız data key-lər yenidən wrap olunur.

Bonus olaraq, data key-i məhv etmək onunla encrypt olunmuş data-nı, backup-lardakı nüsxələr də daxil olmaqla, oxunmaz edir. Bu, silinməsi çətin olan data üçün praktik deletion üsuludur.

Ümumi səhvlər: plaintext data key-i yaddaşda lazım olandan uzun saxlamaq, ciphertext-in yanında key versiyasını saxlamamaq və application-a master key üzərində həddindən artıq geniş permission vermək.

Əlaqəli terminlər: Encryption, Key rotation, Secret, Audit log, Least privilege

Excessive agency

LLM-ə və ya agent-ə tapşırıq üçün lazım olandan çox tool, permission və ya avtonomiya verilməsi; injection və ya model səhvi bu imkanlar qədər zərər yaradır.

Excessive agency OWASP Top 10 for LLM Applications siyahısında LLM06-dır. Risk model-in nə dediyindən yox, nə edə bildiyindən gəlir. Agent-in əlindəki hər tool və hər permission prompt injection uğurlu olanda attacker-in əlinə keçən imkandır.

Üç forması var:

• Çox tool. Agent-ə tapşırığa aid olmayan tool-lar verilib, məsələn customer support agent-ində shell və ya ümumi http_request.
• Çox geniş permission. Agent bütün istifadəçilər üçün bir güclü service account ilə işləyir, ona görə də hər istifadəçi faktiki olaraq onun permission-larını alır.
• Çox avtonomiya. Pul köçürmək, məlumat silmək, xaricə mesaj göndərmək kimi geri qaytarılmaz hərəkətlər insan təsdiqi olmadan icra olunur.

Konkret ssenari: e-məktubları xülasə edən assistant-ın e-məktub göndərmə tool-u da var. Gələn məktubda gizlədilmiş təlimat onu daxili sənədləri xaricə göndərməyə yönəldir. Injection tətik idi, amma zərərin ölçüsünü göndərmə tool-unun mövcudluğu müəyyən etdi.

Müdafiə least privilege-in agent-ə tətbiqidir: tapşırığa görə tool allowlist-i, istifadəçinin adından qısaömürlü və scope-u məhdud credential-lar, geri qaytarılmaz hərəkətlər üçün insan təsdiqi və iterasiya, xərc, tool call sayı üçün sərt limitlər.

Ümumi səhv: problemi prompt-da "yalnız icazə verilən hərəkətləri et" yazaraq həll etməyə çalışmaq. Bu, control deyil; sərhəd model-dən kənarda, kodda və permission-larda olmalıdır.

Əlaqəli terminlər: Least privilege, Agent, Tool use, Prompt injection, Allowlist, Blast radius

Hardening

Sistemi default vəziyyətdən minimum lazımi vəziyyətə gətirmək: lazımsız service-ləri, port-ları, package-ləri və account-ları silmək, təhlükəsiz default-lar təyin etmək.

Hardening attack surface-i azaltmağın sistematik prosesidir. Default quraşdırma rahatlıq üçün optimallaşdırılıb: çox service aktivdir, nümunə account-lar mövcuddur, permission-lar genişdir. Hardening bunların hamısını tapşırığa lazım olan minimuma endirir.

Praktikada:

• Minimal base image-lər, shell və package manager-siz.
• İstifadə olunmayan service-ləri söndürmək və port-ları bağlamaq.
• Default credential-ları və nümunə konfiqurasiyaları silmək.
• Container-ləri non-root və read-only filesystem ilə işlətmək.
• Yazılı patching cadence.

Sıfırdan başlamaq əvəzinə CIS-style benchmark-lardan istifadə edin: onlar OS, container runtime və cloud account-lar üçün hazır checklist-lərdir. Hardening-i image build-ə və infrastructure koduna daxil edin ki, hər yeni instance artıq hardened başlasın.

Ümumi səhv hardening-i bir dəfəlik iş kimi görməkdir. Əl ilə edilən dəyişikliklər, yeni package-lər və "müvəqqəti" açılan port-lar zamanla sistemi geri qaytarır. Immutable infrastructure və drift detection bunun qarşısını alır.

Əlaqəli terminlər: Attack surface, Security misconfiguration, Defence in depth, Least privilege

Hash

İstənilən ölçülü input-dan sabit uzunluqlu "barmaq izi" çıxaran birtərəfli funksiya; geri çevrilmir, integrity yoxlaması və password saxlanması üçün istifadə olunur.

Hash funksiyası istənilən ölçülü data-dan sabit uzunluqlu nəticə çıxarır. Eyni input həmişə eyni hash-i verir, input-da bir bit dəyişsə, hash tamamilə fərqli olur, və hash-dən input-u geri bərpa etmək praktiki olaraq mümkün deyil. Encryption-dan fərqli olaraq burada key yoxdur və əməliyyat geri çevrilmir.

İstifadə halları fərqli tələblər qoyur:

• Integrity yoxlaması. Yüklənmiş package-in checksum-u gözlənilən dəyərlə üst-üstə düşürmü? Burada SHA-256 kimi sürətli kriptoqrafik hash-lər uyğundur.
• Data versioning. Training set-in hash-ini saxlamaq onun dəqiq hansı versiyası ilə işlədiyinizi sübut edir.
• Password saxlanması. Burada sürət düşməndir. Argon2id və ya bcrypt kimi qəsdən yavaş hash-lər istifadə olunur, hər password üçün ayrıca random salt ilə. Salt eyni password-lərin eyni hash verməsinin və əvvəlcədən hesablanmış cədvəllərlə sındırılmasının qarşısını alır.
• Detection. Threat intelligence-də zərərli faylların hash-ləri indicator kimi paylaşılır.

Nümunə: database leak olur. Password-lər SHA-256 ilə, salt-sız saxlanıbsa, attacker GPU ilə saniyədə milyardlarla təxmin yoxlayır. Argon2id ilə isə hər təxmin bahalıdır və zəif olmayan password-lər praktiki olaraq qorunur.

Ümumi səhvlər: password üçün sürətli hash, MD5 və ya SHA-1 kimi köhnəlmiş alqoritmlər, və hash-i encryption ilə qarışdırmaq.

Əlaqəli terminlər: Encryption, Integrity, Credential, Supply chain

Improper output handling

LLM output-unun downstream sistemdə yoxlanmadan render edilməsi, icra olunması və ya query-yə qoyulması; nəticədə XSS, SQL injection və ya command injection yaranır.

Improper output handling OWASP Top 10 for LLM Applications siyahısında LLM05-dir. Səbəb sadədir: attacker model-in output-unu prompt vasitəsilə formalaşdıra bilir, deməli model output-u downstream sistem üçün istifadəçi input-u ilə eyni statusdadır. Onu trusted kimi qəbul etmək klassik injection vulnerability-lərini geri qaytarır.

Tipik hallar:

• Model cavabı HTML kimi render olunur və içindəki script istifadəçinin browser-ində icra olunur (XSS).
• Model-in yaratdığı SQL birbaşa database-də işlədilir.
• Model-in yaratdığı shell əmri və ya kod server-də sandbox olmadan icra olunur.
• Markdown şəklinin URL-i render olunur və query string-də data xarici server-ə sızır.

Müdafiə tədbirləri application security-nin adi qaydalarıdır, sadəcə yeni mənbəyə tətbiq olunur: kontekstə uyğun output encoding, structured output və schema validation, model-ə query yazdırmaq əvəzinə yalnız parametr seçdirmək, kodu sandbox-da icra etmək, render olunan link və şəkillər üçün domain allowlist-i.

Ümumi səhv: output-u "bizim model-imiz yaradıb" deyə trusted saymaq. Model-in context-inə untrusted məzmun düşürsə, onun output-u da untrusted-dir.

Əlaqəli terminlər: XSS, SQL injection, Structured output, Sandbox, Prompt injection, Trust boundary

Incident response

Security incident-ini aşkarlamaqdan bağlamağa qədər idarə etmə prosesi: preparation, identification, containment, eradication, recovery və lessons learned.

Incident response alert həqiqi çıxanda nə edəcəyinizi müəyyən edən planlı prosesdir. Onun dəyəri improvizə etməməkdədir: plan incident-dən əvvəl yazılır, test edilir və hamı öz role-unu bilir.

Standart mərhələlər:

• Preparation. Role-ları olan yazılı plan (incident commander, investigator-lar, communications, hüquqi əlaqə), korporativ e-poçt compromise olunanda da işləyən əlaqə siyahıları, log-lara və forensic tooling-ə əvvəlcədən test edilmiş access, tabletop məşqlər.
• Identification. Incident-in həqiqi olduğunu təsdiqləmək, severity təyin etmək və dərhal timeline başlatmaq.
• Containment. Evidence-i məhv etmədən qanaxmanı dayandırmaq: host-ları isolate etmək, account-ları deaktiv etmək.
• Eradication. Hər backdoor-u, persistence mexanizmini silmək və hər oğurlanmış credential-ı rotate etmək.
• Recovery. Sistemləri known-good mənbələrdən restore etmək və monitoring-i gücləndirmək.
• Lessons learned. İki həftə ərzində blameless review və owner-i olan action-lar siyahısı.

Çətin qərarlardan biri containment-in vaxtıdır: tez contain etmək, yoxsa attacker-in tam əhatəsini öyrənmək üçün müşahidə etmək. Ransomware üçün demək olar ki, həmişə sürət düzgündür.

Ümumi səhvlər: scope-u bilmədən password reset edib attacker-i xəbərdar etmək, sistemləri rebuild etmək əvəzinə "təmizləmək", natamam eradication və breach notification deadline-larını (çox vaxt 72 saat) incident zamanı öyrənmək.

Əlaqəli terminlər: Audit log, Ransomware, Lateral movement, Assume breach

Integrity

CIA triad-ın ikinci xassəsi: data-nın və sistemlərin yalnız icazəsi olanlar tərəfindən, icazə verilən üsullarla dəyişdirilməsi və dəyişikliyin aşkarlana bilməsi.

Integrity data-nın və sistemlərin etibarlı qalmasıdır: heç kim icazəsiz və aşkarlanmadan onları dəyişdirə bilməz. STRIDE-da onu pozan threat tampering adlanır.

Integrity pozuntusu çox vaxt confidentiality pozuntusundan təhlükəlidir, çünki görünmür. Oğurlanmış data ən azı sizdə də qalır; səssizcə dəyişdirilmiş data isə səhv qərarlara, səhv ödənişlərə və etibarın itirilməsinə gətirib çıxarır. Fraud tipik integrity attack-idir.

Integrity-ni qoruyan control-lar:

• Authorization və least privilege yazma əməliyyatlarında. Yalnız lazım olan actor-lar yaza bilir.
• Kriptoqrafik yoxlama. Hash, checksum, digital signature, message authentication code. Signed artifact-lər və verify olunmuş dependency-lər supply chain integrity-sini təmin edir.
• Server-side validation. Client-dən gələn qiymətə, endirimə və ya user ID-yə etibar edilmir.
• Audit log. Kim nəyi nə vaxt dəyişdi.
• Immutable backup-lar. Attacker onları da dəyişdirə bilməsin.

Nümunə: online mağazada səbətdəki məhsulun qiyməti request body-də göndərilir və server onu yoxlamadan qəbul edir. Attacker qiyməti 0.01-ə dəyişir. Bu, klassik integrity pozuntusudur.

Incident-dən sonra recovery zamanı sistemləri yenidən qoşmazdan əvvəl integrity-ni verify etmək lazımdır. Ümumi səhv integrity-ni yalnız database constraint-ləri ilə eyniləşdirmək və client-ə etibar etməkdir.

Əlaqəli terminlər: CIA triad, Hash, Audit log, Supply chain

JWT

İmzalanmış JSON payload daşıyan, server-də session saxlamadan identity ötürmək üçün istifadə olunan token formatı; rahatdır, amma tez-tez yanlış istifadə olunur.

JWT üç hissədən ibarətdir: header (alqoritm), payload (claim-lər, məsələn, user ID, role, expiry) və signature. Server token-in signature-ini yoxlayaraq onun dəyişdirilmədiyinə əmin olur və database-ə müraciət etmədən istifadəçinin kim olduğunu bilir. Bu stateless təbiət onu microservice-lər arasında populyar edir.

Vacib nüans: JWT default olaraq encrypt olunmur, yalnız imzalanır. Payload base64 ilə kodlanıb və hər kəs onu oxuya bilər.

Təhlükəsiz istifadə qaydaları:

• Signature-i icazə verilən alqoritmlərin allowlist-i ilə validate edin. Token-in öz header-indəki alqoritmə etibar etməyin; "alg: none" attack-i məhz bundan istifadə edir.
• Expiry-ni həmişə yoxlayın və access token-ləri qısaömürlü edin.
• Payload-a heç vaxt secret və ya həssas data yerləşdirməyin.
• Token-i yalnız TLS üzərindən ötürün.

Əsas trade-off revocation-dur. JWT expiry-dən əvvəl ləğv edilə bilməz, yalnız denylist saxlasanız mümkündür, bu da stateless cazibənin böyük hissəsini aradan qaldırır. Buna görə praktikada qısaömürlü access token-lər revoke edilə bilən refresh token-lərlə birləşdirilir.

Ümumi səhvlər: 24 saatlıq və ya daha uzun access token-lər, logout-dan sonra da işləyən token-lər, və bütün user obyektini payload-a qoymaq.

Əlaqəli terminlər: Authentication, Credential, Allowlist, Secret

Key rotation

Kriptoqrafik key-in planlı və ya incident-dən sonra yenisi ilə əvəz edilməsi, köhnə data-nın oxuna bilməsini qoruyaraq.

Key rotation yeni key-in istifadəyə verilməsi və köhnəsinin mərhələli şəkildə çıxarılmasıdır. Məqsəd hər key ilə qorunan data həcmini və hər key leak-inin təsir müddətini məhdudlaşdırmaqdır.

Rotation dizayn tələb edir, sonradan əlavə olunmur. Ciphertext hansı key versiyası ilə encrypt olunduğunu daşımalıdır; əks halda yeni key-ə keçəndə köhnə data-nı oxumaq mümkün olmur və komanda köhnə key-i əbədi saxlayır. Tipik ardıcıllıq: yeni key yaradılır, yeni yazılar onunla encrypt olunur, köhnə data fon prosesi ilə yenidən encrypt olunur, sonra köhnə key deaktiv edilir və nəhayət məhv edilir.

Signing key-lər üçün də eyni məntiq keçərlidir: verify edən tərəflər keçid dövründə həm köhnə, həm də yeni public key-i qəbul etməlidir. Buna görə də public key-lər adətən key ID ilə dərc olunur.

Ən vacib test rotation-u incident-dən əvvəl ən azı bir dəfə real olaraq etməkdir. Heç vaxt rotate edilməmiş key rotate edilə bilməyən key-dir, və bunu adətən key leak olanda kəşf edirsiniz.

Əlaqəli terminlər: Envelope encryption, Secret, Incident response, Encryption

Lateral movement

Attacker-in ilk foothold-dan şəbəkə daxilində başqa host-lara, account-lara və service-lərə keçərək dəyərli hədəfə doğru irəliləməsi.

Lateral movement attack-in ilk girişdən sonrakı mərhələsidir. Attacker nadir hallarda birbaşa istədiyi yerə düşür; adətən phishing ilə bir əməkdaşın laptop-unu və ya zəif bir server-i ələ keçirir. Sonra oradan tapdığı credential-larla, açıq şəbəkə yolları ilə və daxili sistemlərdəki zəifliklərlə domain controller-ə, database-lərə və backup-lara doğru hərəkət edir.

Bu mərhələ vacibdir, çünki detection pəncərəsinin böyük hissəsi burada keçir. Ransomware qrupları adətən nəyisə encrypt etməzdən əvvəl şəbəkənin içində günlərlə gəzir, privilege-i escalate edir və data-nı exfiltrate edir. Saatlar içində tapılan attacker-in yalnız foothold-u var; aylar sonra tapılanın hər şeyi.

Lateral movement-i bahalı etməyin yolları:

• Segmentation və micro-segmentation: compromise olunmuş service hər şeyə çata bilməsin.
• Zero trust: daxili request-lər də authenticate və authorize olunur.
• Shared local admin password-lərindən və uzunömürlü service credential-larından qaçmaq.
• Privileged access-i vaxtla məhdudlaşdırmaq.

Detection üçün tipik behavioural siqnallar: service account-un interaktiv login etməsi, workstation-dan server-lərə qeyri-adi connection-lar, yeni scheduled task-lar.

Ümumi səhv flat şəbəkədir: VPN-ə qoşulan hər kəsin hər şeyə çata bildiyi mühit. Belə şəbəkədə ilk foothold faktiki olaraq tam access deməkdir.

Əlaqəli terminlər: Assume breach, Blast radius, Zero trust, Credential

Least privilege

Hər istifadəçi, proses və service-in yalnız öz işi üçün lazım olan minimum access-ə malik olması prinsipi; compromise zamanı zərəri məhdudlaşdırır.

Least privilege sadə səslənir: hər komponent yalnız ona lazım olanı edə bilməlidir, artığını yox. Amma ən çox pozulan prinsiplərdən biridir, çünki geniş icazə vermək həmişə daha tez və daha rahatdır.

Onun dəyəri compromise anında görünür. Hər şey nə vaxtsa ələ keçirilə bilər; bu baş verəndə attacker məhz həmin komponentin edə bildiklərini edə bilir. Least privilege blast radius-u birbaşa kiçildir.

Praktikada:

• Reporting job-u orders cədvəlinə yalnız read access alır, write yox.
• Application-ın database user-i schema-nı dəyişə bilmir.
• Admin hüquqları daimi deyil, konkret tapşırıq üçün, saatlarla və approval ilə verilir.
• CI runner-ləri yalnız deploy etdikləri mühitə çata bilir.
• AI agent-i yalnız tapşırığa lazım olan tool-lara və scope-u məhdud credential-lara malikdir.
• Cloud IAM policy-lərində wildcard (*) əvəzinə konkret action və resource-lar.

Nümunə: marketing üçün qurulmuş e-poçt göndərmə service-inin bütün müştəri database-inə access-i var, çünki "sadəcə bir neçə field lazımdır". Service-dəki SSRF bütün müştəri data-sının leak olmasına çevrilir.

Trade-off: dəqiq icazələr idarə etmək üçün səy tələb edir və çox sərt olanda komandalar işləyə bilmir, nəticədə yenidən hər şeyi açırlar. Ümumi səhv icazələri yalnız əlavə etmək və heç vaxt istifadə olunmayanları geri almamaqdır.

Əlaqəli terminlər: Blast radius, Authorization, RBAC, Defence in depth, Zero trust

MAC

Shared secret key ilə hesablanan qısa dəyər; mesajın dəyişdirilmədiyini və key-i bilən tərəfdən gəldiyini sübut edir.

MAC mesaj və secret key-dən hesablanan tag-dır. Qəbul edən tərəf eyni key ilə tag-ı yenidən hesablayır və müqayisə edir; uyğun gəlirsə, mesaj yolda dəyişdirilməyib və key-ə sahib olan tərəfdən gəlib. Ən geniş yayılmış forması HMAC-SHA256-dır.

Adi hash ilə fərq key-dədir. Mesajın yanında yalnız SHA-256 göndərilirsə, attacker mesajı dəyişib hash-i yenidən hesablaya bilər. MAC-ı isə key olmadan düzgün hesablamaq mümkün deyil.

Digital signature ilə fərq key-in növündədir. MAC-da hər iki tərəf eyni secret-i bilir, buna görə də üçüncü tərəfə mesajı kimin yaratdığını sübut etmək olmur. Signature-da private key yalnız bir tərəfdədir və hər kəs public key ilə verify edə bilir.

Tipik istifadə halları: webhook-ların verify olunması, daxili service mesajları, signed cookie-lər, URL-lərin müddətli imzalanması.

Ümumi səhvlər: tag-ı adi string müqayisəsi ilə yoxlamaq (timing attack-ə imkan verir; constant-time müqayisə lazımdır), timestamp daxil etməyib replay-ə yol açmaq və eyni key-i encryption və MAC üçün təkrar istifadə etmək.

Əlaqəli terminlər: Hash, Integrity, Secret, JWT

Mass assignment

API-nin request body-ni birbaşa obyektə bind etməsi nəticəsində istifadəçinin dəyişməməli olduğu field-ləri, məsələn role və ya balance-ı dəyişə bilməsi.

Mass assignment endpoint-in gələn JSON-u yoxlamadan database modelinə köçürdüyü halda yaranır. Profil yeniləyən PATCH /api/users/me request-inə istifadəçi "display_name" ilə yanaşı "role": "admin" və ya "credit_balance": 99999 əlavə edir. Server bu field-ləri gözləmirdi, amma framework onları obyektə yazır və yadda saxlayır.

Bu, OWASP API Security Top 10 2023-də API3, yəni broken object property level authorization riskinin "yazma" tərəfidir. İstifadəçinin obyektə access-i var, amma onun hər field-inə yox.

Həll açıq allowlist-dir:

• Hər endpoint üçün yazıla bilən field-lərin ayrıca schema-sı və ya DTO-su.
• Gözlənilməyən field-ləri sükutla atmaq əvəzinə rədd etmək və log etmək.
• Database modelini birbaşa API contract-ına çevirməmək.

Denylist yanaşması ("role field-ini qəbul etmə") işləmir, çünki modelə gələcəkdə əlavə olunan hər yeni həssas field avtomatik olaraq açıq qalır.

Əlaqəli terminlər: Broken object property level authorization, Allowlist, Authorization

MFA

İki və ya daha çox müstəqil factor tələb edən authentication: bildiyiniz, sahib olduğunuz və ya olduğunuz şey. Credential oğurluğuna qarşı ən effektiv control-dur.

MFA password-ün tək başına kifayət etmədiyi authentication-dur. Factor-lar üç növdür: bildiyiniz (password), sahib olduğunuz (telefon, hardware key) və olduğunuz (biometric). Attacker password-ü ələ keçirsə belə, ikinci factor olmadan login edə bilmir.

Amma ikinci factor-ların hamısı eyni dərəcədə güclü deyil:

• SMS kodları. Heç nədən yaxşıdır, amma SIM swapping və interception-a həssasdır.
• Authenticator app-lər (TOTP). Yaxşıdır, amma real-time phishing proxy-si kodu istifadəçidən alıb dərhal istifadə edə bilər.
• Push notification-lar. Rahatdır, amma "MFA fatigue"-ə həssasdır: attacker istifadəçi bezib "approve" basana qədər prompt göndərir. Number matching bunu azaldır.
• Hardware key-lər və passkey-lər (FIDO2/WebAuthn). Phishing-resistant-dır, çünki credential saytın origin-inə bağlıdır və saxta domain-də işləmir.

Tövsiyə: MFA-nı bütün əməkdaşlar və bütün admin access-i üçün məcburi edin, bütün istifadəçilərə təklif edin, elevated access-i olanlar üçün isə phishing-resistant factor-lar tələb edin.

Ümumi səhvlər: MFA-nı əsas login-də tətbiq edib password reset, API token-ləri və ya köhnə protokollar kimi yan yolları açıq qoymaq; recovery axınını SMS-ə bağlamaq; və MFA prompt-larını log edib monitor etməmək. Qeyri-adi sayda push təsdiqi özü bir detection siqnalıdır.

Əlaqəli terminlər: Authentication, Phishing, Credential, Zero trust

mTLS

Hər iki tərəfin certificate təqdim etdiyi TLS: server client-i, client də server-i authenticate edir. Service-lərarası trafik üçün geniş istifadə olunur.

Adi TLS-də yalnız server certificate təqdim edir; client isə adətən password, token və ya API key ilə application səviyyəsində authenticate olunur. mTLS-də client də öz certificate-ini təqdim edir və server onu verify edir. Nəticədə bağlantı qurulmamışdan əvvəl hər iki tərəfin identity-si məlum olur.

mTLS əsasən machine-to-machine trafikdə istifadə olunur: service-lər, job-lar, daxili API-lər. Zero trust yanaşmasında "daxili şəbəkədəndir" etibar səbəbi deyil; mTLS hər service-ə kriptoqrafik identity verir və authorization qərarları IP ünvanına deyil, bu identity-yə əsaslanır.

Praktikada əsas çətinlik certificate-lərin idarə olunmasıdır. Hər workload üçün certificate issue etmək, onları qısaömürlü saxlamaq və avtomatik rotate etmək lazımdır. Bunu adətən service mesh və ya platformanın workload identity mexanizmi edir; əl ilə idarə olunan, illərlə etibarlı certificate-lər isə sadəcə başqa formada uzunömürlü secret-dir.

Ümumi səhv mTLS-i authorization ilə qarışdırmaqdır. mTLS "kim danışır?" sualına cavab verir; "bu service bu əməliyyatı edə bilərmi?" sualı hələ də ayrıca yoxlanmalıdır.

Əlaqəli terminlər: TLS, Zero trust, Authentication, Authorization, Lateral movement

OAuth 2.0

Application-a istifadəçinin password-unu vermədən, scope-la məhdud və qısaömürlü access token vasitəsilə onun adından resource-lara access verən authorization protokolu.

OAuth 2.0 "delegated access" problemini həll edir. İstifadəçi third-party application-a öz təqvimini və ya fayllarını oxumaq icazəsi vermək istəyir, amma ona password-unu vermək istəmir. OAuth-da istifadəçi authorization server-də authenticate olur, hansı scope-lara razılıq verdiyini görür, application isə yalnız həmin scope-larla işləyən access token alır.

Əsas rollar dörddür: resource owner (istifadəçi), client (application), authorization server (token verən) və resource server (token-i qəbul edən API).

Vacib nüans: OAuth authorization protokoludur, authentication deyil. Access token "bu client-ə nə etməyə icazə var" sualına cavab verir, "istifadəçi kimdir" sualına yox. İstifadəçinin identity-si üçün onun üzərində qurulan OpenID Connect istifadə olunur.

Bu gün tövsiyə olunan flow-lar:

• Authorization code + PKCE: browser, mobile və server application-ları üçün.
• Client credentials: istifadəçi olmayan service-to-service çağırışlar üçün.
• Device flow: klaviaturası olmayan cihazlar üçün.

Implicit və resource owner password flow-ları deprecated sayılır.

Ən çox rast gəlinən səhvlər: redirect URI-nin wildcard və ya prefix ilə yoxlanması, state parametrinin yoxlanmaması, lazım olandan geniş scope-lar və resource server-in token-in aud claim-ini yoxlamaması.

Əlaqəli terminlər: OpenID Connect, JWT, Authorization, Authentication, Least privilege

OpenID Connect

OAuth 2.0-ın üzərində qurulan identity qatı: ID token vasitəsilə istifadəçinin kim olduğunu təsdiqləyir və SSO-nun əsasını təşkil edir.

OpenID Connect OAuth 2.0-a çatışmayan hissəni, yəni authentication-u əlavə edir. Login-dən sonra client access token-lə yanaşı ID token da alır. ID token istifadəçi haqqında claim-lər daşıyan imzalanmış JWT-dir: kim olduğu (sub), kim tərəfindən təsdiqləndiyi (iss), kim üçün verildiyi (aud) və nə vaxt authenticate olduğu.

İki token-in rolları fərqlidir və onları qarışdırmaq ən çox rast gəlinən səhvdir:

• ID token client üçündür: "istifadəçi kimdir?" Onu API-yə göndərmək olmaz.
• Access token API üçündür: "bu çağırışa icazə varmı?" Onu istifadəçinin identity sübutu kimi qəbul etmək olmaz.

ID token-i qəbul etməzdən əvvəl signature, iss, aud, exp və login request-də göndərilmiş nonce yoxlanmalıdır. nonce köhnə ID token-in replay edilməsinin qarşısını alır.

OIDC bir identity provider-in bir çox application üçün login etməsinə, yəni SSO-ya imkan verir. Bu, MFA və account deaktivasiyasını bir yerdə idarə etməyə imkan verir, amma identity provider-i ən dəyərli hədəfə çevirir.

Əlaqəli terminlər: OAuth 2.0, JWT, Authentication, MFA

Phishing

İstifadəçini saxta mesaj və ya sayt vasitəsilə credential, MFA kodu və ya başqa həssas məlumat verməyə, ya da zərərli faylı açmağa aldatmaq.

Phishing texniki sistemlərə yox, insanlara hücumdur. Attacker bank, IT departamenti, rəhbər və ya tanınmış SaaS adından mesaj göndərir; istifadəçi linkə keçir, saxta login səhifəsində password-ü daxil edir və ya əlavəni açır. Breach-lərin əksəriyyəti məhz belə başlayır.

Phishing inkişaf edib. Kütləvi, səhvlərlə dolu e-poçtlarla yanaşı, konkret şəxsə hazırlanmış spear phishing və real-time phishing proxy-ləri var: istifadəçi saxta saytda password və TOTP kodu daxil edir, proxy isə onları dərhal real sayta ötürür və session cookie-ni oğurlayır. Bu halda adi MFA belə kömək etmir.

Müdafiə əsasən texniki olmalıdır, çünki insanlar nə vaxtsa səhv edəcək:

• Phishing-resistant MFA: passkey-lər və FIDO2 hardware key-ləri origin-ə bağlıdır və saxta domain-də işləmir.
• E-poçt authentication (SPF, DKIM, DMARC) və link filtering.
• Least privilege: bir account ələ keçiriləndə zərər məhdud qalır.
• Yeni device-dan və ya qeyri-adi yerdən login-lər üçün detection.

Təlim faydalıdır, amma məqsəd insanları "heç vaxt klikləməyən" etmək deyil, şübhəli şeyi tez bildirməyə öyrətməkdir. Məlumat verən əməkdaşı günahlandırmaq gələcək hesabatları susdurur.

Ümumi səhv phishing-i istifadəçi problemi saymaqdır. Bir klik bütün şirkəti compromise edə bilirsə, bu, system design problemidir.

Əlaqəli terminlər: MFA, Credential, Authentication, Threat actor

Policy-as-code

Security və compliance qaydalarını kod kimi yazmaq və CI-də və ya deploy zamanı avtomatik yoxlamaq; qaydaya uyğun gəlməyən dəyişiklik bloklanır.

Policy-as-code "public bucket yoxdur", "storage encrypt olunmalıdır", "container root kimi işləməməlidir" kimi qaydaları wiki səhifəsindən icra olunan koda çevirir. Qaydalar version control-da saxlanır, review olunur və test edilir.

Yoxlama bir neçə nöqtədə aparıla bilər:

• CI-də: infrastructure as code dəyişikliyi merge olunmazdan əvvəl.
• Admission zamanı: orchestrator signed olmayan və ya privileged image-i qəbul etmir.
• Runtime-da: mövcud resource-lar davamlı olaraq qaydalara qarşı scan olunur.

Üstünlüyü ardıcıllıqdır: insan review-u yorulur və qaçırır, qayda isə hər dəyişikliyə eyni tətbiq olunur. Review-çu konkret qaydanı yoxlamaq əvəzinə design-a fokuslana bilir.

Ümumi səhv qaydaları çox sərt başlatmaqdır: hər şeyi bloklayan policy-lər tez bir zamanda "disable" edilir. Əvvəl warning rejimində başlayın, noise-u azaldın, sonra enforce edin. İstisnalar da kodda, səbəbi və bitmə tarixi ilə yazılsın.

Əlaqəli terminlər: Security misconfiguration, Hardening, CSPM, Supply chain

Ransomware

Sistemləri və data-nı encrypt edən, çox vaxt əvvəlcə data-nı kopyalayıb leak etməklə də hədələyən və geri qaytarmaq üçün fidyə tələb edən zərərli proqram.

Ransomware mütəşəkkil cinayətkarlığın ən gəlirli biznes modelidir. Klassik forması sadədir: zərərli proqram faylları və serverləri encrypt edir və decryption key üçün pul tələb edir. Bu, availability-yə birbaşa attack-dir.

Müasir ransomware əməliyyatları daha mürəkkəbdir:

• İlkin giriş çox vaxt phishing, oğurlanmış credential və ya patch olunmamış edge device vasitəsilə olur, bəzən initial-access broker-lərdən satın alınır.
• Attacker günlərlə şəbəkədə qalır, lateral movement edir, admin hüquqları toplayır.
• Backup-ları tapıb silir və ya encrypt edir.
• Data-nı exfiltrate edir, sonra encrypt edir. Beləliklə ikiqat təzyiq yaranır: həm availability, həm də confidentiality.

Ən vacib müdafiə backup-lardır: offline və ya immutable, attacker-in admin credential-ları ilə də silinə bilməyən, və ən əsası, həqiqətən restore edərək test edilmiş. Recovery vaxtı demək olar ki, tamamilə buna bağlıdır, və bu tək control əksər detection investisiyalarından dəyərlidir.

Digər control-lar: MFA, segmentation, privileged access-in məhdudlaşdırılması, ilkin mərhələlərdə detection.

Incident zamanı ransomware üçün demək olar ki, həmişə sürətli containment düzgündür. Ümumi səhvlər: backup-ları production ilə eyni domain və credential-larla saxlamaq, restore-u heç vaxt sınamamaq və təmizlənmiş sistemləri rebuild etmədən geri qaytarmaq.

Əlaqəli terminlər: Availability, Incident response, Lateral movement, Threat actor

RBAC

Role-based access control: istifadəçilərə role-lar, role-lara isə permission-lar verilən authorization modeli. Sadə, audit edilə bilən, amma kobud.

RBAC-də istifadəçi birbaşa permission almır; ona role verilir (viewer, editor, billing-admin), role isə permission-lar toplusudur. Kimin nə edə biləcəyini anlamaq üçün istifadəçinin role-larına baxmaq kifayətdir, bu da audit-i asanlaşdırır. Sistemlərin əksəriyyəti buradan başlamalıdır.

Onun məhdudiyyəti dənəvərlikdir. RBAC "editor sənədləri redaktə edə bilər" deyir, amma "yalnız öz komandasının sənədlərini, iş saatlarında" demək çətindir. Bunun üçün iki alternativ model var:

• ABAC (attribute-based): qərarlar istifadəçinin, resource-un və kontekstin attribute-larına əsaslanır, məsələn, department, data classification, vaxt, device. Çox çevikdir, amma qaydaları mühakimə etmək və test etmək çətinləşir.
• ReBAC (relationship-based): permission-lar graph-dakı əlaqələri izləyir: "sənədin owner-i", "qovluğa sahib olan komandanın üzvü". Google Zanzibar-ın və müasir sənəd paylaşma sistemlərinin arxasındakı model.

Praktikada çox vaxt hibrid yaranır: RBAC əsas çərçivəni verir, object-level check-lər isə ownership əlaqəsini yoxlayır.

Nümunə: SaaS-da "admin" role-u var. Sonra "yalnız faktura görən admin", "yalnız istifadəçi əlavə edən admin" lazım olur, və bir ildən sonra 40 role yaranır. Bu, role explosion adlanır və ABAC və ya ReBAC-a keçid siqnalıdır.

Ümumi səhv role-u authorization-un tamamı saymaq və obyekt səviyyəsində ownership-i yoxlamamaqdır.

Əlaqəli terminlər: Authorization, Least privilege, Broken object-level authorization, Audit log

Sandbox

Kodun və ya prosesin host sistemdən təcrid olunmuş, fayl, şəbəkə və resource access-i məhdudlaşdırılmış mühitdə icra edilməsi.

Sandbox etibar etmədiyiniz və ya tam nəzarət edə bilmədiyiniz kodu icra etmək üçün qurulmuş təcrid olunmuş mühitdir. İçəridəki proses yalnız açıq şəkildə icazə verilən fayllara, şəbəkə ünvanlarına və system call-lara çata bilir. Nəsə səhv getsə, zərər sandbox-un divarları daxilində qalır.

Sandbox-lar müxtəlif səviyyələrdə qurulur:

• Browser-lər hər tab-ı ayrıca, imkanları məhdud prosesdə işlədir.
• Container-lər və onların seccomp profilləri, daha güclü təcrid üçün gVisor və ya Firecracker kimi microVM-lər.
• WebAssembly runtime-ları.
• Ayrıca, qısaömürlü virtual maşınlar.

Bu anlayış AI agent-ləri ilə xüsusilə aktuallaşıb. Agent kod yazıb icra edirsə, fayl sistemində əməliyyat aparırsa və ya prompt injection ilə aldadıla bilirsə, onu sandbox-da işlətmək blast radius-u kiçiltməyin əsas yoludur. Sandbox-un şəbəkə egress-i də məhdudlaşdırılmalıdır, əks halda zərərli təlimat data-nı xaricə göndərə bilər.

Nümunə: istifadəçilərin yüklədiyi faylları emal edən image converter. Parser-də vulnerability olsa belə, sandbox daxilində attacker-in nə credential-ı, nə daxili şəbəkəsi, nə də davamlı fayl sistemi olur.

Ümumi səhvlər: container-i tam sandbox saymaq, sandbox-a production secret-lərini mount etmək və geniş şəbəkə access-i vermək. Sandbox yalnız onun içinə qoyduğunuz qədər güclüdür.

Əlaqəli terminlər: Blast radius, Least privilege, Agent, Prompt injection

Secret

Sistemin access verdiyi və gizli qalmalı olan dəyər: API key, database password-ü, private key, signing key, token. Kodda deyil, secrets manager-də saxlanılır.

Secret machine-lərin istifadə etdiyi credential-dır: database password-ü, cloud access key, third-party API key, TLS private key, JWT signing key. Onları bilən hər kəs həmin sistemə access əldə edir.

Source repository-lərdə ən çox rast gəlinən kritik tapıntı commit edilmiş secret-dir. Repository klonlanır, fork olunur, CI log-larına düşür, və bir dəfə commit edilmiş secret git history-də qalır.

Əsas qaydalar:

• Secret-lər heç vaxt source koda, repository-dəki config fayllarına, container image-lərinə və ya log-lara yazılmır.
• Secrets manager istifadə olunur (Vault, cloud provider-in secret service-i) və secret-lər runtime-da inject edilir.
• Hər commit pre-commit hook və CI-də secret pattern-ləri üçün scan olunur, push bloklanır.
• Secret-lər avtomatik rotate olunur. Heç vaxt rotate edilməmiş secret rotate edilə bilməyən secret-dir, və bunu incident zamanı kəşf edəcəksiniz.
• Scope minimaldır: hər service öz secret-ini alır, shared key-lər yoxdur.

Leak olanda ona dərhal compromise olunmuş kimi yanaşın: əvvəl rotate edin, sonra araşdırın. Secret-i git history-dən silmək leak-i geri qaytarmır; onu artıq kimsə klonlamış ola bilər.

Ən yaxşı secret heç olmayan secret-dir: workload identity ilə platform qısaömürlü credential-ları avtomatik verir və uzunömürlü key saxlamağa ehtiyac qalmır.

Əlaqəli terminlər: Credential, Encryption, Supply chain, JWT

Security misconfiguration

Kod bug-ı deyil, səhv və ya default konfiqurasiya nəticəsində yaranan vulnerability: public storage, açıq port-lar, default credential-lar, production-da debug mode.

Security misconfiguration sistemin düzgün yazıldığı, amma səhv qurulduğu haldır. Kod təhlükəsiz ola bilər, lakin onu işlədən mühit qapını açıq qoyur.

Tipik nümunələr:

• Public edilmiş storage bucket-də müştəri export-ları.
• İnternet-ə açıq SSH, RDP və ya database port-u.
• Authentication-sız orchestrator API-si və ya admin dashboard.
• Dəyişdirilməmiş default credential-lar.
• Production-da debug mode və stack trace-li error səhifələri.
• Həddindən artıq icazəli CORS və ya IAM policy.

Cloud-da bu, breach-lərin ən çox rast gəlinən səbəbidir, çünki bir config sətri bütün data-nı internet-ə aça bilər, və scanner-lər bütün address space-i saatlar içində gəzir.

Müdafiə konfiqurasiyanı kod kimi idarə etməkdir: infrastructure as code, review, policy-as-code ilə avtomatik yoxlama, drift detection və davamlı posture scanning. Default-ları təhlükəsiz edin, istisnaları açıq qərar kimi sənədləşdirin.

Əlaqəli terminlər: Hardening, Policy-as-code, CSPM, Attack surface, Shared responsibility model

Shadow API

Təşkilatın API inventarında və sənədlərində olmayan, buna görə də security control-larından kənarda qalan endpoint; köhnə, amma hələ işləyən versiyalar isə zombie API adlanır.

Shadow API-lər müxtəlif yollarla yaranır: debug üçün açılıb unudulmuş route, gateway-dən yan keçib birbaşa expose olunmuş service, komandanın sənədləşdirməyə ehtiyac duymadığı "daxili" endpoint. Onlar OWASP API Security Top 10 2023-də API9, yəni improper inventory management riskinin əsas hissəsidir.

Zombie API-lər onların qohumudur: rəsmi olaraq deprecate olunmuş, amma hələ də cavab verən köhnə versiyalar. /v2/users düzgün authorization-a malikdir, /v1/users isə iki il əvvəlki kodla işləyir və attacker məhz onu çağırır.

Hər iki halda problem eynidir: bilmədiyiniz endpoint-i patch etmir, monitor etmir və test etmirsiniz.

Müdafiə:

• İnventarı sənədlərdən yox, real trafikdən qurun: gateway log-larındakı route-ları OpenAPI spec-ləri ilə müqayisə edin.
• Hər işləyən versiya eyni authentication, authorization və monitoring control-larına malik olsun, və ya söndürülsün.
• Deprecation-un sonunda versiyanı həqiqətən söndürün və ona gələn trafiki alert kimi izləyin.

Əlaqəli terminlər: Attack surface, API versioning, API gateway

Shared responsibility model

Cloud provider ilə müştəri arasında security məsuliyyətinin bölgüsü: provider platform-u qoruyur, müştəri isə öz konfiqurasiyasını, identity-lərini və data-sını.

Shared responsibility model cloud-da "bunu kim qoruyur?" sualına cavab verir. Provider fiziki data center-lərə, hypervisor-a və idarə etdiyi service-lərin daxili hissəsinə cavabdehdir. Müştəri isə onların üzərində qurduğu hər şeyə cavabdehdir.

Sərhəd service modelinə görə dəyişir. IaaS-da OS patching, network konfiqurasiyası və runtime müştərinindir. PaaS və serverless-də bu layer-lərin çoxu provider-ə keçir. SaaS-da müştəriyə ən az iş qalır. Amma iki şey heç vaxt provider-ə keçmir:

• Kimin nəyə access-i olduğu: account-lar, role-lar, MFA, permission-lar.
• Data-nın özü: classification-ı, kimlə paylaşıldığı, nə vaxt silindiyi.

Cloud breach-lərinin əksəriyyəti provider-in səhvi deyil, məhz müştəri tərəfindəki boşluqlardır: public bucket, wildcard policy, leak olmuş access key. Ümumi səhv "biz cloud-dayıq, security provider-in işidir" düşüncəsidir. Provider platform-un təhlükəsiz olmasını təmin edir; sizin onu təhlükəsiz istifadə etməyinizi yox.

Əlaqəli terminlər: Security misconfiguration, Least privilege, Serverless, CSPM

SQL injection

Untrusted input-un SQL query-yə concatenate edilərək data kimi yox, kod kimi icra olunduğu klassik injection vulnerability-si.

SQL injection injection sinfinin kanonik nümunəsidir: untrusted input downstream sistem tərəfindən kod kimi şərh edilir. Developer istifadəçi input-unu birbaşa query string-ə birləşdirəndə input-un özü query-nin strukturunu dəyişə bilir.

Məsələn, "SELECT * FROM users WHERE name = '" + name + "'" sətrində name dəyəri ' OR '1'='1 olarsa, şərt həmişə doğru olur və bütün istifadəçilər qaytarılır. Daha pis variantlarda attacker başqa cədvəlləri oxuyur, data-nı dəyişir və ya bəzi database-lərdə əmr icra edir.

Həll həmişə eynidir: data-nı və kodu bunun üçün nəzərdə tutulmuş interface vasitəsilə ayrı saxlamaq. Parameterised query-də query strukturu ayrıca, dəyərlər isə ayrıca göndərilir, və input heç vaxt kod kimi şərh olunmur. ORM-lər də default olaraq bunu edir, amma raw query yazan anda qoruma itir.

Eyni pattern başqa yerlərdə də təkrarlanır:

• Shell əmrləri: string əvəzinə argument array-ləri.
• LDAP və NoSQL query-ləri.
• Template-lər: auto-escaping.
• Dil modellərinə göndərilən prompt-lar, yəni prompt injection.

Validation və sanitisation ikinci dərəcəli müdafiədir. Escape funksiyaları ilə "təmizləmək" kontekstləri qaçırır.

Ümumi səhvlər: sütun adı və ORDER BY kimi parameterise oluna bilməyən hissələri allowlist-siz birləşdirmək, və application-ın database user-inə lazımından çox icazə vermək.

Əlaqəli terminlər: XSS, Allowlist, Defence in depth, Prompt injection

SSRF

Server-side request forgery: application-ın istifadəçinin verdiyi URL-i fetch etməsindən istifadə edib server-i daxili service-lərə və ya cloud metadata endpoint-lərinə yönəltmək.

SSRF application-ın xaricdən URL qəbul edib onu server tərəfdən fetch etdiyi hər yerdə yaranır: webhook-lar, link preview-lar, "URL-dən şəkil yüklə" feature-ləri, PDF generator-ları, import funksiyaları. Attacker xarici URL əvəzinə daxili ünvan verir və server onun adından request göndərir.

Bu təhlükəlidir, çünki server-in şəbəkə mövqeyi attacker-inkindən daha privileged-dir. Server daxili admin panel-lərə, firewall arxasındakı database-lərə və ən əsası cloud metadata endpoint-inə (169.254.169.254) çata bilir. Cloud mühitlərində metadata endpoint-i instance-ın IAM credential-larını qaytara bilər, və SSRF birbaşa cloud account-unun ələ keçirilməsinə çevrilir.

Müdafiə layer-ləri:

• Destination-lar üçün allowlist: yalnız gözlənilən host-lar.
• Private və link-local address range-lərini bloklamaq, DNS resolve-dan sonra yoxlamaqla, çünki attacker daxili IP-yə resolve olan domain istifadə edə bilər.
• Redirect-ləri izləməmək və ya hər redirect-i yenidən yoxlamaq.
• Fetch əməliyyatını privileged şəbəkə mövqeyi olmayan, təcrid olunmuş service-də icra etmək.
• Cloud-da metadata service-in session tələb edən versiyasını (məsələn, IMDSv2) istifadə etmək.

Ümumi səhvlər: yalnız URL string-ini regex ilə yoxlamaq, IPv6 və onluq IP formatlarını unutmaq, və fetch edən service-ə geniş IAM role-u vermək.

Əlaqəli terminlər: Allowlist, Trust boundary, Least privilege, Credential

STRIDE

Altı threat kateqoriyasının qısaltması: Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, Elevation of privilege. Threat modelling-də sistemli yoxlama üçün istifadə olunur.

STRIDE threat modelling zamanı "nə səhv gedə bilər?" sualını sistemli etmək üçün mnemonik qısaltmadır. Hər hərf bir threat kateqoriyasıdır və hər biri bir security xassəsini pozur:

• Spoofing: başqası kimi özünü göstərmək. Authenticity-ni pozur; authentication ilə mitigate olunur.
• Tampering: data-nı aşkarlanmadan dəyişdirmək. Integrity-ni pozur; integrity check-ləri və yazmada least privilege ilə.
• Repudiation: etdiyini inkar etmək. Accountability-ni pozur; audit log ilə.
• Information disclosure: görməməli olduğu data-nı görmək. Confidentiality-ni pozur; encryption və access control ilə.
• Denial of service: sistemi əlçatmaz etmək. Availability-ni pozur; rate limiting və capacity ilə.
• Elevation of privilege: icazəsi olmayan şeyi etmək. Authorization-u pozur; hər boundary-də authorization check-ləri ilə.

İstifadə qaydası: data flow diagram-ı götürün və hər elementi, xüsusilə trust boundary-ni keçən hər oxu altı sualla gəzin. "Browser → API" üçün: request başqa istifadəçi adından saxtalaşdırıla bilərmi (CSRF)? Parametrlər dəyişdirilə bilərmi? Response artıq data qaytarırmı? Bir client API-ni tükəndirə bilərmi? ID dəyişmək admin davranışı verirmi?

Nəticə konkret elementlərə bağlanmış threat siyahısıdır; orta ölçülü sistem üçün onlarla.

STRIDE-ın zəif tərəfi zəncirlənmiş attack-ləri qaçırmasıdır, buna görə onu attack tree ilə tamamlamaq faydalıdır. Ümumi səhv onu bir dəfəlik workshop kimi keçirməkdir.

Əlaqəli terminlər: Threat model, Data flow diagram, Trust boundary, Attack tree, CIA triad

Supply chain

Sizin qurmadığınız, amma asılı olduğunuz hər şey: dependency-lər, build tool-ları, CI action-ları, container image-ləri, modellər və dataset-lər. Attacker onları hədəf ala bilər.

Supply chain attack-də attacker sizin kodunuza deyil, sizin istifadə etdiyiniz koda hücum edir. Application-lar əsasən başqalarının kodundan ibarətdir və hər dependency, hər build plugin-i, hər CI action-ı öz kodunu sizin pipeline-ınızda, sizin credential-larınızla icra edir.

Tipik ssenarilər:

• Populyar package-in maintainer account-u ələ keçirilir və zərərli versiya publish olunur.
• Typosquatting: məşhur library adına bənzər adla zərərli package.
• Zəhərlənmiş CI action-ı və ya build plugin-i secret-ləri oğurlayır.
• Third-party model, dataset və ya prompt backdoor daşıyır.
• Köhnəlmiş, məlum vulnerability-si olan library birbaşa giriş yolu olur.

Müdafiə tədbirləri:

• Dependency versiyalarını pin etmək və checksum-ları verify etmək.
• Lockfile-lardan istifadə etmək və onlardakı dəyişiklikləri review etmək.
• Az transitive dependency-si olan, aktiv maintain olunan library-lərə üstünlük vermək.
• Dependency scanning və software bill of materials.
• CI runner-lərinin çata bildiklərini məhdudlaşdırmaq; onlar privileged mövqedir.
• Build artifact-lərini sign etmək və deploy zamanı verify etmək; reproducible build-lər.

Nümunə: CI-da istifadə olunan action-ın tag-i attacker tərəfindən yeni commit-ə yönəldilir və o, environment-dəki bütün secret-ləri log-a çıxarır. Action commit SHA ilə pin edilsəydi, bu baş verməzdi.

Ümumi səhv lockfile dəyişikliklərini "avtomatik yenilənmə" deyə review etmədən merge etməkdir.

Əlaqəli terminlər: Integrity, Hash, Secret, Attack surface, Artifact

System prompt leakage

System prompt-un məzmununun istifadəçiyə və ya attacker-ə üzə çıxması; əsl risk orada saxlanmamalı olan secret-lər və security məntiqidir.

System prompt leakage OWASP Top 10 for LLM Applications siyahısında LLM07-dir. Model-dən system prompt-u təkrarlamasını, tərcümə etməsini və ya "debug üçün" göstərməsini istəmək çox vaxt işləyir, və bunun qarşısını etibarlı şəkildə almaq mümkün deyil.

Buna görə də düzgün yanaşma leakage-in qarşısını almaq yox, onun zərərsiz olmasını təmin etməkdir. System prompt-u public sənəd kimi qəbul edin.

Orada olmamalı olanlar:

• API key, password, connection string və digər secret-lər.
• Daxili URL-lər və infrastructure detalları.
• Authorization məntiqi: "istifadəçi admin-dirsə, bu məlumatı göstər" kimi qaydalar.
• Filter və guardrail qaydalarının tam siyahısı, əgər onların bilinməsi bypass-ı asanlaşdırırsa və başqa control yoxdursa.

Əgər system prompt-un üzə çıxması təhlükəlidirsə, problem leakage-də deyil, dizayndadır. Secret-lər secrets manager-də, authorization isə model-dən kənarda, kodda olmalıdır. Model istifadəçinin permission-larından artıq heç nəyə çata bilməməlidir; o zaman system prompt-u oxuyan attacker heç nə qazanmır.

Əlaqəli terminlər: Secret, Prompt, Authorization, Prompt injection, Guardrail

Threat actor

Sistemə hücum edə biləcək şəxs və ya qrup; imkanları və motivi ilə xarakterizə olunur və nəyə qarşı müdafiə olunmalı olduğunuzu müəyyən edir.

Threat actor "kimdən qorunuruq?" sualının cavabıdır. Actor-lar imkan və motiv baxımından kəskin fərqlənir, və bu fərq müdafiə büdcəsinin hara getməli olduğunu göstərir.

Əsas kateqoriyalar:

• Fürsətçi cinayətkarlar. Tez pul üçün avtomatlaşdırılmış scanning, məlum exploit-lər, phishing kit-ləri.
• Mütəşəkkil cinayətkarlıq. Ransomware əməliyyatları, initial-access broker-lər, səbirli social engineering.
• Insider-lər. Narazılıq, pul və ya sadəcə səhv; qanuni credential-ları və daxili bilikləri var.
• Hacktivist-lər. Diqqət və ideologiya; defacement, leak-lər, denial of service.
• Dövlət dəstəkli qruplar. Casusluq və pozuntu; zero-day-lər, supply chain compromise-i, illərlə səbir.

Praktik nəticə: təşkilatların əksəriyyəti heç vaxt dövlət actor-u ilə üzləşməyəcək və sanki üzləşəcəkmiş kimi xərcləməməlidir. Amma demək olar ki, hər təşkilat fürsətçi cinayətkarlıqla fasiləsiz üzləşir və elə indi scan edildiyini fərz etməlidir. Bu o deməkdir ki, əsas gigiyena (patch-lər, MFA, secret-lərin kodda olmaması) ekzotik müdafiələrdən daha vacibdir.

Threat modelling zamanı actor-u adlandırmaq threat-ləri realist edir: "kənar attacker" yerinə "oğurlanmış support credential-ı olan cinayətkar" daha konkret sual yaradır.

Ümumi səhvlər: insider-ləri, xüsusilə səhvən zərər verən əməkdaşları nəzərə almamaq, və ya əksinə, yalnız ən güclü actor-a qarşı plan qurub əsasları unutmaq.

Əlaqəli terminlər: Threat model, Phishing, Ransomware, Attack tree

Threat model

Sistem üçün dörd suala cavab verən praktika: nə qururuq, nə səhv gedə bilər, bununla bağlı nə edəcəyik və işi yaxşı gördükmü.

Threat modelling ən yüksək təsir gücünə malik security fəaliyyətidir, çünki kod yazılmazdan əvvəl, design qüsurunu düzəltməyin migration yox, lövhə silgisi qədər ucuz olduğu vaxtda baş verir. Onun nəticəsi, yəni threat model, sistemə qarşı real threat-lərin və onlara verilən cavabların canlı sənədidir.

Proses dörd suala ardıcıl cavab verir:

• Nə qururuq? Trust boundary-ləri olan data flow diagram.
• Nə səhv gedə bilər? Hər boundary keçidinə STRIDE tətbiq etmək; yüksək dəyərli hədəflər üçün attack tree.
• Nə edəcəyik? Hər threat üçün dörd cavabdan biri: mitigate, eliminate, transfer və ya accept. Prioritet sadə balla: ehtimal × impact.
• İşi yaxşı gördükmü? Mitigation-ları test etmək; "rate limiting ilə mitigate olunub" deyilirsə, rate limit-in işlədiyini sübut edən test olmalıdır.

Qəbul edilmiş risk-lər yazılı olmalıdır: səbəb, qəbul edən şəxs və yenidən baxılma tarixi.

Threat model sistem dəyişən anda köhnəlir. Ona yeni trust boundary əlavə olunanda, yeni data kateqoriyası yarananda, incident-dən sonra və ən azı ildə bir dəfə qayıdın.

Uğurlu komandalarda bu, vərdişdir: hər design sənədinin qısa "threat-lər" bölməsi var, developer-lər otuz dəqiqəlik STRIDE keçidini özləri edir. Ümumi səhv onu konsultantla birdəfəlik workshop-a çevirmək və ya mükəmməl model axtarışında heç başlamamaqdır.

Əlaqəli terminlər: STRIDE, Data flow diagram, Trust boundary, Attack tree, Fitness function

Timing attack

Əməliyyatın nə qədər vaxt apardığını ölçərək secret haqqında məlumat çıxaran side-channel attack.

Timing attack kodun cavab vermə vaxtının input-dan asılı olmasından istifadə edir. Klassik nümunə token-in və ya HMAC-ın adi string müqayisəsi ilə yoxlanmasıdır: müqayisə ilk fərqli simvolda dayanır, ona görə də düzgün başlayan təxmin bir az daha uzun çəkir. Kifayət qədər çox ölçmə ilə attacker dəyəri simvol-simvol bərpa edə bilər.

Daha geniş yayılmış forma isə account enumeration-dur. Login endpoint-i mövcud olmayan istifadəçi üçün dərhal cavab verir, mövcud olan üçün isə yavaş password hash-ini hesablayır. Error mesajı eyni olsa belə, vaxt fərqi hansı email-lərin qeydiyyatda olduğunu göstərir.

Müdafiə:

• Secret-ləri, token-ləri və MAC-ları crypto library-nin constant-time müqayisə funksiyası ilə yoxlayın.
• Login və password reset-də hər iki yolda eyni işi görün: istifadəçi tapılmasa da hash hesablayın və eyni cavabı qaytarın.
• Rate limiting attacker-in ehtiyac duyduğu ölçmələrin sayını məhdudlaşdırır.

Əlaqəli terminlər: Authentication, Hash, JWT

TLS

Şəbəkə bağlantısını encrypt edən və server-in identity-sini certificate ilə sübut edən protokol; HTTPS-in əsası.

TLS iki tərəf arasındakı bağlantıya üç xassə verir: confidentiality (trafiki kənar şəxs oxuya bilmir), integrity (trafik yolda dəyişdirilə bilmir) və server authentication (client həqiqətən gözlədiyi server ilə danışır). Handshake zamanı asymmetric kriptoqrafiya ilə session key razılaşdırılır, sonrakı trafik isə symmetric authenticated encryption ilə ötürülür.

Server-in identity-si certificate ilə sübut olunur: etibarlı certificate authority server-in public key-ini domain adına bağlayır. Client certificate zəncirini, domain adını və müddətini yoxlamalıdır. Bu yoxlama söndürüləndə TLS hələ də encrypt edir, amma kiminlə danışdığınızı bilmirsiniz; man-in-the-middle attacker-i öz certificate-ini təqdim edib bütün trafiki oxuya bilir.

Praktik baseline:

• TLS 1.2 minimum, TLS 1.3 üstünlük; SSL və TLS 1.0/1.1 söndürülür.
• HTTPS hər yerdə, HSTS ilə.
• Certificate-lər avtomatik yenilənir, expire olmuş certificate səbəbindən validation söndürülmür.
• Daxili service-lərarası trafik də TLS ilə gedir.

Ümumi səhv "test üçün" söndürülmüş certificate validation-un production-a çatmasıdır. Bu kod code review-da və secret scanning-ə bənzər avtomatik check-lərlə axtarılmalıdır.

Əlaqəli terminlər: mTLS, Encryption, Confidentiality, Integrity, Zero trust

Trust boundary

Sistemdə trust səviyyəsinin dəyişdiyi xətt, məsələn, internet ilə API, service ilə database, tenant ilə tenant arasında. Threat-lər məhz bu keçidlərdə yaşayır.

Trust boundary iki tərəfin bir-birinə eyni dərəcədə etibar etmədiyi sərhəddir. İnternet ilə DMZ arasında, browser ilə API arasında, application ilə database arasında, A tenant-ı ilə B tenant-ı arasında, hətta AI modeli ilə onun oxuduğu xarici sənəd arasında belə bir xətt var.

Threat modelling-in məğzi bu xətlərdir. Boundary-ni keçən hər data flow az etibar edilən tərəfdəki attacker-in daha çox etibar edilən tərəfə təzyiq göstərə biləcəyi yerdir. Data flow diagram-da onlar nöqtəli xətlərlə çəkilir və STRIDE ilk növbədə bu keçidlərə tətbiq olunur.

Praktik qaydalar:

• Boundary-ni keçən hər şey, istər şəbəkədən, istər istifadəçidən, istər fayldan, istərsə də başqa service-dən gəlsin, validate olunana qədər düşməndir.
• Validation, authentication və authorization boundary-nin etibarlı tərəfində olur, client-də yox.
• Boundary-dən çıxan data üçün output encoding və minimal məlumat.

Nümunə: frontend yalnız istifadəçinin öz ID-sini göndərir deyə backend onu yoxlamır. Amma browser boundary-nin etibarsız tərəfindədir və istifadəçi request-i istədiyi kimi dəyişə bilər.

Yeni boundary yarananda (yeni integration, yeni tenant tipi, yeni deployment target-i, model-ə verilən yeni tool) threat model-ə yenidən baxmaq lazımdır. Ümumi səhv daxili service-lər arasındakı boundary-ləri görməməkdir: "daxili şəbəkədir" fərziyyəsi zero trust-ın rədd etdiyi köhnə perimeter modelidir.

Əlaqəli terminlər: Threat model, Data flow diagram, STRIDE, Zero trust, Prompt injection

XSS

Cross-site scripting: untrusted input-un veb səhifəyə HTML və ya script kimi render olunub digər istifadəçilərin browser-lərində icra olunduğu vulnerability.

XSS veb üçün injection-dur. Attacker istifadəçi məzmununa (şərh, profil adı, URL parametri) script yerləşdirir, application isə onu escape etmədən səhifəyə render edir. Nəticədə attacker-in kodu qurbanın browser-ində, qurbanın session-u ilə, saytın origin-i adından işləyir: session token-lərini oğurlaya, istifadəçi adından hərəkətlər edə, səhifəni saxta login formasına çevirə bilər.

React, Vue, Angular kimi müasir framework-lər default olaraq output-u escape edir, buna görə XSS əsasən bu qoruma qəsdən söndürüləndə yenidən ortaya çıxır:

• dangerouslySetInnerHTML, v-html və ya birbaşa innerHTML istifadəsi.
• HTML-i string-lərdən əl ilə qurmaq.
• İstifadəçi məzmununu framework-ün əhatə etmədiyi kontekstlərdə render etmək: href attribute-u (javascript: URL-ləri), inline style, script daxilində JSON.

Müdafiə:

• Kontekstə uyğun output encoding: HTML, attribute, URL və JavaScript kontekstləri fərqli encoding tələb edir.
• Raw HTML lazımdırsa, sübut olunmuş sanitizer library-si ilə allowlist əsaslı təmizləmək.
• Sərt Content Security Policy, inline script-ləri qadağan edən.
• Session cookie-lərini HttpOnly etmək ki, script onları oxuya bilməsin.
• Hər raw-HTML render-ini security review üçün səbəb saymaq.

Ümumi səhv input-u saxlama zamanı encode etməyə çalışmaqdır: bu, data-nı pozur və yenə də render kontekstlərini qaçırır.

Əlaqəli terminlər: SQL injection, Allowlist, Trust boundary, JWT

Zero trust

Şəbəkə mövqeyinə etibarı fasiləsiz verification ilə əvəz edən yanaşma: hər request identity, device health və kontekst əsasında authenticate və authorize olunur.

Köhnə model şəbəkə perimeter-i daxilindəki hər şeyə etibar edirdi: VPN-ə qoşulmusansa, "içəridəsən". Remote iş, cloud service-lər və attacker-lərin lateral movement-i bu modeli mənasız etdi. Zero trust bunun əvəzinə hər request-i, haradan gəlməsindən asılı olmayaraq, eyni şübhə ilə qarşılayır.

Praktikada zero trust bu elementlərdən ibarətdir:

• İstifadəçilər və workload-lar üçün güclü identity: MFA, workload identity, qısaömürlü credential-lar.
• Access-dən əvvəl device posture check-ləri: device patch olunub, disk encrypt olunub, şirkət tərəfindən idarə olunur.
• Flat şəbəkəyə VPN əvəzinə per-application access.
• Micro-segmentation: compromise olunmuş service hər şeyə çata bilmir.
• Hər access qərarının log-lanması.

Nümunə: əməkdaş internal wiki-yə açır. Köhnə modeldə VPN kifayət idi. Zero trust modelində identity provider istifadəçini MFA ilə yoxlayır, device-ın managed olduğunu təsdiqləyir, və yalnız wiki-yə access verir, bütün şəbəkəyə yox. Laptop oğurlansa və ya malware yoluxsa, attacker başqa sistemlərə avtomatik çatmır.

Zero trust product deyil, istiqamətdir. Heç bir vendor onu qutuda satmır. Ən yüksək dəyərli application-lardan və ən privileged istifadəçilərdən başlayın.

Ümumi səhvlər: onu yalnız şəbəkə layihəsi saymaq, service-to-service trafikini unutmaq və hər addımda MFA tələb edərək istifadəçiləri bezdirmək; yaxşı zero trust çox vaxt görünməzdir.

Əlaqəli terminlər: Assume breach, Least privilege, MFA, Lateral movement, Trust boundary