Dlaczego projekt jest najtańszym miejscem na błąd
Koszt naprawy luki bezpieczeństwa rośnie z każdym etapem, na którym zostaje niezauważona. Błąd w projekcie architektury to zmiana na diagramie. Ten sam błąd wykryty przez pentestera na dwa tygodnie przed podpisaniem umowy to przeprojektowanie działającego systemu, retesty i przesunięty termin.
Większość narzędzi bezpieczeństwa działa na gotowym kodzie — skanery znajdują to, co już zostało napisane. Modelowanie zagrożeń działa wcześniej: pyta o problemy, zanim powstanie pierwsza linia kodu. To dlatego jest jedną z najbardziej opłacalnych praktyk w całym procesie wytwórczym.
Czym jest modelowanie zagrożeń
Modelowanie zagrożeń to ustrukturyzowana rozmowa o tym, co może pójść nie tak w projektowanym systemie i co z tym zrobimy. Nie jest to audyt ani skan. To metoda patrzenia na architekturę oczami kogoś, kto chciałby ją zaatakować.
W praktyce sprowadza się do czterech pytań:
- Co budujemy? (diagram systemu i przepływów danych)
- Co może pójść nie tak? (zagrożenia)
- Co z tym robimy? (kontrole)
- Czy zrobiliśmy to dobrze? (weryfikacja)
Pierwsze pytanie brzmi banalnie, ale jest źródłem większości wartości. Zespół, który rysuje własny system i przepływy danych, regularnie odkrywa granice zaufania i ścieżki, o których wcześniej nikt nie myślał świadomie.
STRIDE — sześć kategorii, o które się pyta
STRIDE to najczęściej używana metoda kategoryzowania zagrożeń. Nazwa to skrót od sześciu typów:
- Spoofing — podszywanie się pod kogoś lub coś. Czy potrafimy potwierdzić, że rozmówca jest tym, za kogo się podaje?
- Tampering — nieuprawniona modyfikacja danych lub kodu. Czy dane w tranzycie i w spoczynku są chronione przed zmianą?
- Repudiation — wyparcie się działania. Czy mamy ślad tego, kto co zrobił?
- Information disclosure — wyciek informacji. Czy dane trafiają tylko do tych, którzy mają do nich prawo?
- Denial of service — odmowa działania. Czy da się system przeciążyć albo zablokować?
- Elevation of privilege — podniesienie uprawnień. Czy da się zrobić więcej, niż powinno się móc?
STRIDE nie daje odpowiedzi — daje strukturę pytań. Idąc kategoria po kategorii przez każdy element diagramu, zespół systematycznie sprawdza obszary, które w nieustrukturyzowanej dyskusji łatwo pominąć.
Wartość STRIDE nie polega na znajdowaniu egzotycznych ataków. Polega na tym, że nie da się o czymś „zapomnieć” — każda granica zaufania przechodzi przez ten sam zestaw pytań.
Jak to wygląda w praktyce
Punktem wyjścia jest diagram przepływu danych rzeczywistego systemu, nie przykład z podręcznika. Zaznacza się na nim elementy (usługi, magazyny danych, procesy zewnętrzne) oraz granice zaufania — miejsca, w których dane przechodzą między obszarami o różnym poziomie zaufania.
Następnie, przechodząc przez granice i przepływy, zespół zadaje pytania STRIDE. Każde znalezione zagrożenie zapisuje się razem z decyzją: mitygujemy, akceptujemy ryzyko, czy przenosimy je gdzie indziej. Efektem nie jest raport do szuflady, tylko lista konkretnych rzeczy do zrobienia wpiętych w backlog zespołu.
Dobre modelowanie zagrożeń jest rozmową inżynierów, nie prezentacją eksperta. Zespół, który sam przeszedł przez ten proces, następnym razem potrafi go powtórzyć bez zewnętrznej pomocy.
Najczęstszy błąd: jednorazowy warsztat
Najczęstszy sposób, w jaki modelowanie zagrożeń przestaje działać, to potraktowanie go jako jednorazowego wydarzenia. Zespół robi warsztat, powstaje diagram, po kwartale system się zmienił, a diagram został na dysku i nikt do niego nie wraca.
Zagrożenia zmieniają się razem z systemem. Nowa integracja, nowy magazyn danych, nowa ścieżka uwierzytelnienia — każde z nich zmienia obraz. Modelowanie, które nie nadąża za zmianami, po kilku miesiącach opisuje system, który już nie istnieje.
Wpięcie w proces wytwórczy
Dlatego modelowanie zagrożeń ma sens jako element procesu, nie jako osobny projekt. Praktycznie oznacza to kilka rzeczy:
- lekkie modelowanie przy każdej istotnej zmianie architektury, a nie tylko raz na start,
- diagram trzymany blisko kodu, wersjonowany razem z nim,
- osoby w zespole, które umieją prowadzić modelowanie samodzielnie — bez wąskiego gardła w postaci jednego eksperta.
Zbudowane w ten sposób modelowanie zagrożeń przestaje być kosztem, a staje się sposobem, w jaki zespół projektuje. To ta sama zasada, która przewija się przez cały bezpieczny proces wytwórczy: bezpieczeństwo wbudowane w sposób pracy działa, doklejone po fakcie — nie.