Użyteczny model zagrożeń wyjaśnia, co chronisz, kto lub co może na to wpływać, gdzie zmienia się zaufanie oraz jak ograniczysz i przetestujesz najważniejsze ryzyka. Zacznij od rzeczywistego projektu, a nie od ogólnej listy narzędzi.
Zdefiniuj zakres wystarczająco mały, by można było o nim rozumować
Zacznij od jednej działającej usługi: portalu klienta, serwisu publikacyjnego lub aplikacji wewnętrznej. Zapisz komponenty, którymi zarządzasz, i systemy zewnętrzne, od których zależysz. Model zagrożeń powinien uwidaczniać założenia, a nie sugerować, że rozwiązano każdy możliwy atak. Utrzymaj pierwszą wersję na tyle małą, by osoby wdrażające aplikację mogły ją wyjaśnić bez osobnego konsultanta interpretującego diagram.
Wymień cenne rezultaty i zasoby. Mogą one obejmować dane klientów, dostęp administracyjny, stan płatności, publikowane treści i możliwość przywrócenia usługi. Dostępność może być zasobem, nawet gdy informacje są publiczne. Zdecyduj, które awarie byłyby uciążliwe, a które zaszkodziłyby ludziom lub organizacji. To rozróżnienie pomaga ustalić priorytety kontroli, zamiast traktować każde ostrzeżenie jednakowo.
Narysuj miejsca, w których zmienia się zaufanie
Wytyczne OWASP dotyczące modelowania zagrożeń wykorzystują przepływy danych i granice zaufania, aby uczynić projekt zrozumiałym. W przypadku małej hostowanej aplikacji narysuj przeglądarkę, proces webowy, bazę danych, administratora, miejsce docelowe kopii zapasowych i integracje zewnętrzne. Zaznacz informacje przemieszczające się między nimi. Żądanie przechodzące od niezaufanego klienta do uprzywilejowanej operacji serwera zasługuje na wyraźną walidację i autoryzację.
Nie zakładaj, że samo znajdowanie się na tej samej maszynie czyni każdy komponent równie zaufanym. Publiczny proces przesyłania plików nie powinien mieć tych samych uprawnień co administracja bazą danych. Zadanie tworzenia kopii zapasowej może potrzebować dostępu do odczytu bez możliwości modyfikowania aktywnych rekordów aplikacji. Rozdzielenie tych ról ułatwia ograniczenie skutków przejęcia komponentu i przegląd wymaganych uprawnień.
Wybierz konkretne scenariusze awarii
Użyj kilku prawdopodobnych zdarzeń, aby zakwestionować projekt. Atakujący kradnie hasło administratora; użytkownik żąda rekordu innego użytkownika; przesłany plik zapełnia dysk; wdrożenie ujawnia plik konfiguracyjny; kopia odzyskiwania nie daje się odtworzyć. Opisz warunek początkowy, dotknięty komponent i konsekwencję. Konkretny scenariusz łatwiej przetestować niż ogólną instrukcję poprawy bezpieczeństwa.
Uwzględnij błędy i nadużycia zgodnych z przepisami procesów, a także wtargnięcie z zewnątrz. Ponowna próba może utworzyć dwie wartościowe operacje albo dwa żądania mogą wyścignąć się o zmianę tego samego obiektu. Wytyczne OWASP dotyczące logiki biznesowej podkreślają te założenia procesu. Sprawdź, kto może przenieść proces do następnego stanu i czy powtórzenie lub zmiana kolejności żądania nieoczekiwanie zmienia wynik.
| Scenariusz | Kontrola do zbadania | Dowody do zebrania |
|---|---|---|
| Skradzione dane uwierzytelniające administratora | Ograniczony dostęp i drugi czynnik, jeśli jest obsługiwany | Nieautoryzowane logowanie nie może się zakończyć |
| Zażądano obiektu innego użytkownika | Autoryzacja obiektu po stronie serwera | Izolowany test zwraca wynik odmowy |
| Dysk zapełniony przez przesłane pliki | Kontrole rozmiaru, limitów i przechowywania | Limit jest egzekwowany przed awarią usługi |
| Zduplikowane żądanie procesu | Idempotencja i granice transakcji | Powtórzone żądanie tworzy jeden wynik |
Ustal priorytety według wpływu i wiarygodnej ścieżki
Dla każdego scenariusza zapisz jego potencjalny wpływ i warunki wymagane do jego wystąpienia. Nie udawaj, że zgadnięta ocena liczbowa jest dokładnym prawdopodobieństwem. Nadal możesz odróżnić słabe hasło wystawione na internet od wysoce warunkowego zdarzenia lokalnego. Przypisz właściciela i praktyczny następny krok do ważnych ryzyk, aby model tworzył pracę, którą ktoś może faktycznie wykonać.
Rozważ cykl życia informacji, a także przejęcie aplikacji. Eksport diagnostyczny może ujawnić niepotrzebne dane podczas skądinąd normalnego działania. Zachowane pole konta może tworzyć narażenie długo po zakończeniu jego celu. Przegląd prywatności może zatem usunąć informacje lub skrócić okres przechowywania, a przegląd bezpieczeństwa ograniczyć dostęp do tego, co pozostaje. Obie zmiany należą do modelu, gdy chronią projekt.
Przetestuj kontrole w autoryzowanym środowisku
Utwórz środowisko testowe z reprezentatywnymi uprawnieniami i fikcyjnymi rekordami. Przetestuj odmowę dostępu, limity żądań, ponowienia procesów i odzyskiwanie. Nie używaj prawdziwych danych klientów, gdy dane syntetyczne mogą wykazać zachowanie. Celem jest zweryfikowanie kontroli, a nie wygenerowanie imponującego ruchu atakującego. Pozostań w systemach, które posiadasz lub do oceny których masz wyraźną autoryzację.
Zapisz, co się powiodło, co nie i co pozostaje nieznane. Wynik skanera może dostarczyć dowodów, ale nie zastępuje testu reguł biznesowych aplikacji. Podobnie opcja ochrony sieci nie weryfikuje autoryzacji obiektów ani obsługi plików z sekretami. Dołącz przydatne wyniki do scenariusza, aby przyszli opiekunowie rozumieli, dlaczego dana kontrola istnieje.
Utrzymuj model w powiązaniu ze zmianami
Przejrzyj odpowiednie części, gdy dodajesz integrację, udostępniasz nowy punkt końcowy, zmieniasz uprawnienia lub przenosisz dane do innego miejsca docelowego. Nie musisz przerysowywać całej architektury z powodu drobnej edycji tekstu. Wyzwalaczem jest zmienione założenie dotyczące dostępu, informacji lub zachowania systemu. Trzymaj model obok dokumentacji wdrożeniowej i odzyskiwania, zamiast pozostawiać go jako jednorazowy wynik warsztatów.
SwissOctet dostarcza katalog wyborów infrastrukturalnych, a nie gotowy model zagrożeń aplikacji. Wybierz konfigurację i opcje, które wspierają Twoje kontrole, a następnie zweryfikuj wdrożenie, które budujesz. Mały, utrzymywany model z przetestowanymi działaniami jest bardziej przydatny niż duży zbiór produktów bezpieczeństwa bez jasnego wyjaśnienia ryzyk, które adresują.
Twoja praktyczna lista kontrolna.
- Wymień zasoby i konsekwencje awarii.
- Narysuj przepływy danych i granice zaufania.
- Wybierz konkretne scenariusze włamania, błędu i przepływu pracy.
- Przypisz kontrole i właścicieli do ważnych ryzyk.
- Testuj z danymi syntetycznymi w autoryzowanym środowisku.
- Przejrzyj model, gdy zmieni się istotne założenie.
Szczegóły, które mają znaczenie.
Czy potrzebuję formalnych ram, aby zacząć?+
Nie. Mały diagram i udokumentowany zestaw scenariuszy mogą być przydatne. Ramy pomagają zapewnić spójny przegląd ryzyk.
Czy skaner podatności zastępuje modelowanie zagrożeń?+
Nie. Skanery mogą znaleźć słabości techniczne, podczas gdy model zagrożeń bada również założenia projektowe, uprawnienia i przepływy pracy biznesowej.
Jak często aktualizować model?+
Aktualizuj odpowiednie części, gdy zmieniają się przepływy danych, integracje, uprawnienia lub udostępniona funkcjonalność, i regularnie przeglądaj nierozwiązane ryzyka.
Przejdź do źródła.
Te źródła wspierają koncepcje techniczne w tym przewodniku. Przed zmianą systemu produkcyjnego zapoznaj się z aktualną dokumentacją.
- OWASP: Ściągawka dotycząca modelowania zagrożeń cheatsheetseries.owasp.org
- OWASP: Modelowanie zagrożeń w praktyce devguide.owasp.org
- OWASP: Bezpieczeństwo logiki biznesowej cheatsheetseries.owasp.org
Wskazówki redakcyjne SwissOctet. Przykłady są ilustracyjne. Specyfikacje usług, dostępne opcje i warunki umowne należy zweryfikować osobno.