Przejdź do treści

Threat modeling (modelowanie zagrożeń)

Definicja

Threat modeling to metoda identyfikowania, co może pójść źle w systemie, jak może dojść do ataku i jakie kontrole ograniczają ryzyko.

Co to w zasadzie jest?

To plan: co jest cenne, kto może to zaatakować, jak to zrobi i co z tym robimy.

Zamiast zakładać, że będzie dobrze, opisujesz realne scenariusze. Ktoś może próbować wyciągnąć dane z modelu, podmienić dokumenty w bazie, wstrzyknąć instrukcje do promptu albo nadużyć uprawnień.

Threat modeling jest przydatny nawet w małych projektach. Często ujawnia proste braki: brak logów, brak ograniczeń, brak potwierdzeń dla akcji albo brak zasad danych.

Praktyczne zastosowania (konkretne scenariusze)

Scenariusz 1: Chatbot z danymi klientów

  • Cel: wykrycie ryzyk przed wdrożeniem.
  • Wejście: opis chatbota i zakres danych.
  • Kroki: assety -> zagrożenia -> kontrole.
  • Rezultat: lista zabezpieczeń do wdrożenia.
  • Zabezpieczenie: DLP, IAM i human-in-the-loop.

Scenariusz 2: System RAG

  • Cel: ochrona przed złymi źródłami.
  • Wejście: lista źródeł i proces aktualizacji.
  • Kroki: oceń źródła -> opisz ataki -> dodaj kontrole.
  • Rezultat: mniejsze ryzyko data poisoning.
  • Zabezpieczenie: provenance i cytowanie źródeł.

Scenariusz 3: Integracja z narzędziami

  • Cel: ograniczenie niechcianych akcji.
  • Wejście: lista narzędzi dostępnych dla modelu.
  • Kroki: uprawnienia -> scenariusze nadużyć -> limity.
  • Rezultat: bezpieczniejsze tool calling.
  • Zabezpieczenie: allowlista, logi i potwierdzenia.

Ryzyka i jak je ograniczać

Ryzyko 1: Pominięcie realnych scenariuszy ataku

  • Ryzyko: Pominięcie realnych scenariuszy ataku.
  • Jak ograniczać: używaj red-teamingu i aktualizuj model zagrożeń.

Ryzyko 2: Dokument bez wpływu na wdrożenie

  • Ryzyko: Dokument bez wpływu na wdrożenie.
  • Jak ograniczać: powiąż go z checklistami, testami i monitoringiem.

Ryzyko 3: Zbyt ogólny opis ryzyka

  • Ryzyko: Zbyt ogólny opis ryzyka.
  • Jak ograniczać: przypisuj właściciela i konkretną kontrolę.

Checklista “zanim użyjesz”

  • Czy wiesz, jakie dane i funkcje są najcenniejsze?
  • Czy masz listę możliwych nadużyć?
  • Czy każdemu ryzyku przypisano kontrolę?
  • Czy model zagrożeń wraca przy zmianach systemu?

Diagram

flowchart LR
    A[Asset]
    B[Threat]
    C[Attack surface]
    D[Control]
    E[Owner]
    A --> B --> C --> D --> E

Diagram pokazuje prosty tok modelowania zagrożeń: od zasobu do kontroli i osoby odpowiedzialnej.

Dalsza lektura

Miejsce w mapie

Powiązane hasła