Threat modelling
Threat modelling
Threat modelling sistem haqqında dörd suala ardıcıllıqla cavab vermək praktikasıdır:
- Nə qururuq?
- Nə səhv gedə bilər?
- Bununla bağlı nə edəcəyik?
- İşi yaxşı gördükmü?
Bu, ən yüksək təsir gücünə malik security fəaliyyətidir, çünki kod hələ mövcud olmazdan əvvəl, design qüsurunu düzəltməyin migration deyil, lövhə silgisi qədər başa gəldiyi vaxtda baş verir.
Nə qururuq?
Diaqramla başlayın. Öz-özlüyündə architecture diaqramı deyil, aşağıdakıları göstərən data flow diagram:
- External entity-lər: istifadəçilər, third-party service-lər, 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 hərəkət etdiyini göstərən oxlar.
- Trust boundary-lər: trust səviyyəsinin dəyişdiyi yerlərdə nöqtəli xətlər. İnternetdən DMZ-yə. Browser-dən API-yə. Service-dən database-ə. A tenant-ından B tenant-ına.
Məsələnin məğzi trust boundary-lərdir. Bu boundary-ni keçən hər ox, 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. Threat-lər məhz bu keçidlərdə yaşayır.
Diaqramı bir səhifəyə sığacaq qədər kiçik saxlayın. Sığmırsa, subsystem-i model edin.
Nə səhv gedə bilər? STRIDE
STRIDE altı threat kateqoriyası üçün mnemonik qısaltmadır. Diaqramdakı hər element, xüsusilə də hər boundary keçidi üçün hansılarının tətbiq olunduğunu soruşun.
| Threat | Pozduğu xassə | Nümunə sual |
|---|---|---|
| Spoofing | Authenticity | Kimsə bu istifadəçi və ya service kimi özünü göstərə bilərmi? |
| Tampering | Integrity | Bu flow-dakı və ya store-dakı data aşkarlanmadan dəyişdirilə bilərmi? |
| Repudiation | Accountability | Kimsə bunu etdiyini inkar edə bilərmi, əksini sübut edəcək dəlil olmadan? |
| Information disclosure | Confidentiality | Kimsə görməməli olduğu data-nı görə bilərmi? |
| Denial of service | Availability | Kimsə bunu qanuni istifadəçilər üçün əlçatmaz edə bilərmi? |
| Elevation of privilege | Authorization | Kimsə icazəsi olmayan bir şeyi edə bilərmi? |
Diaqramı sistemli şəkildə gəzin. "Browser → API" oxu üçün:
- Spoofing: request başqa istifadəçi adından saxtalaşdırıla bilərmi? (session handling, CSRF)
- Tampering: request parametrləri ötürülmə zamanı və ya istifadəçi tərəfindən dəyişdirilə bilərmi? (TLS, server-side validation)
- Information disclosure: response-da istifadəçinin görməli olduğundan artıq məlumat varmı? (over-fetching, həddindən artıq ətraflı error-lar)
- Denial of service: bir client API-ni tükəndirə bilərmi? (rate limit-lər, bahalı endpoint-lər)
- Elevation: parametrin dəyişdirilməsi admin davranışı verə bilərmi? (object-level authorization)
Nəticə hər biri konkret elementə bağlanmış threat-lər siyahısıdır. Orta ölçülü sistem üçün onlarla threat gözləyin.
Attack tree-lər
Yüksək dəyərli hədəflər üçün attack tree attacker-in məqsədindən geriyə doğru işləyir. Root: "başqa müştərinin invoice-larını oxumaq". Uşaq düyünlər: buna nail olmağın yolları. Nəvə düyünlər: bunların hər birinə nail olmağın yolları. Leaf-lər konkret attack-lərdir. Ehtimal və xərclə qeyd edin.
Attack tree-lər diaqram üzərində STRIDE-ın qaçıra biləcəyi yolları, məsələn, bir neçə kiçik zəifliyi zəncirləyən attack-ləri üzə çıxarır.
Bununla bağlı nə edəcəyik?
Hər threat dörd cavabdan birini alır:
- Mitigate. Ehtimalı və ya impact-i azaldan control əlavə edin. Threat-lərin əksəriyyəti bura düşür.
- Eliminate. Threat-i yaradan feature-i və ya flow-u silin. Az istifadə olunur və çox vaxt ən yaxşı variantdır.
- Transfer. Sığorta, müqavilələr və ya məsuliyyəti bunu daha yaxşı bacaran provider-ə keçirmək.
- Accept. Risk-in dözüləbilən olduğuna qərar verin, səbəbini yazın, kimin qəbul etdiyini göstərin və yenidən baxılma tarixini təyin edin.
Sadə balla prioritetləşdirin: ehtimal × impact. Tam kəmiyyət risk analizi nadir hallarda özünü doğruldur; threat siyahısı üzrə ardıcıl ikioxlu sıralama isə doğruldur.
Mitigation-lar Fəsil 1-dəki prinsiplərə uyğun gəlir. Spoofing authentication ilə mitigate olunur. Tampering integrity check-ləri və yazma əməliyyatlarında least privilege ilə. Information disclosure encryption və access control ilə. Denial of service rate limiting və capacity ilə. Elevation hər boundary-də authorization check-ləri ilə.
İşi yaxşı gördükmü?
Threat model canlı sənəddir. Sistem dəyişən anda o, səhv olur. Ona yenidən baxın:
- Yeni trust boundary əlavə olunanda (yeni integration, yeni tenant tipi, yeni deployment target-i).
- Yeni data kateqoriyası ortaya çıxanda (ödəniş data-sı, sağlamlıq data-sı, uşaqların data-sı).
- Incident-dən sonra, model-in nəyi qaçırdığını tapmaq üçün.
- Təqvim üzrə, ən azı ildə bir dəfə.
Mitigation-ları test edin. "Rate limiting ilə mitigate olunmuş" threat-in rate limit-in işlədiyini sübut edən test-i olmalıdır. Control-ların mövcudluğunu təsdiq edən security test-ləri threat modelling-in fitness function-larıdır.
Vərdişə çevirmək
Threat modelling konsultantla birdəfəlik workshop olanda uğursuz olur. O, aşağıdakı hallarda uğur qazanır:
- Hər design sənədinin, qısa olsa belə, "threat-lər" bölməsi var.
- Developer-lər otuz dəqiqəyə yüngül STRIDE keçidini özləri edə bilir.
- Yüksək riskli olanlara security sahəsində dərin biliyi olan biri review edir.
- Qəbul edilmiş risk-lərin siyahısı rəhbərliyə görünür.
Məqsəd mükəmməl model deyil. Məqsəd "bunu necə quraq?" soruşmazdan əvvəl refleks olaraq "burada nə səhv gedə bilər?" soruşan komandadır.
Tapşırıqlar
- Tanıdığınız bir sistem üçün trust boundary-lərlə data flow diagram çəkin. Boundary keçidlərini sayın.
- Ən həssas keçidə STRIDE tətbiq edin. Ən azı altı threat sadalayın.
- Hər threat üçün qərar verin: mitigate, eliminate, transfer, yoxsa accept. Bir sətirlik əsaslandırma yazın.