W większości projektów z którymi miałem do czynienia, bezpieczeństwo jest uwzględniane bezpośrednio jedynie w końcowej fazie projektu – tuż przed wdrożeniem, gdy są wykonywane testy bezpieczeństwa. Oczywiście na tym etapie rozwoju projektu nie może być mowy o poważnych zmianach, więc pozostaje „łatanie” długiej listy znalezionych podczas testów "dziur" i gaszenie kolejnych „pożarów". W mojej prezentacji chciałbym pokazać na konkretnym przykładzie, że myślenie o bezpieczeństwie już od samego początku nie jest trudne i bolesne a minimalny wkład pracy na wczesnych etapach może zaoszczędzić wszystkim bólu głowy na końcu projektu. Na przykładzie prostej aplikacji przeanalizujemy jej bezpieczeństwo modelując zagrożenia i skonstrujemy dla niej adekwatne zabezpieczenia. Prezentacja z konferencji #4Developers

1. Wojciech
Dworakowski
Projektowanie zabezpieczeń
aplikacji nie tylko dla orłów.
Case study e-płatności

2. 2
login: Wojciech Dworakowski
 Testowanie i doradztwo dotyczące
bezpieczeństwa aplikacji i systemów IT
 od 2003 roku / ponad 300 systemów i
aplikacji
 OWASP Poland Chapter Leader
 Cel: Podnoszenie świadomości w zakresie
bezpieczeństwa aplikacji

3. 3
Rosnące koszty usuwania
błędów
Definiowanie
Projektowanie
Wytwarzanie
Wdrażanie
Utrzymanie
Dotyczy to
również defektów
bezpieczeństwa!

4. 4
Definiowanie
• Identyfikacja
ryzyka
• Do kluczowych
ryzyk są
dobierane
zabezpieczenia
• Zdefiniowanie
wymagań
Projektowanie
• Wymagania są
weryfikowane w
projekcie
Wykonanie
• Testy
jednostkowe
zabezpieczeń i
poprawności
kodu (według
przyjętych
wymagań)
Wdrażanie
• Testy odbiorcze
– w zakresie
odpowiadającym
przyjętym
wymaganiom
Wymagania
Software Security Development
Lifecycle

5. 5
Definiowanie
• Identyfikacja
ryzyka
• Do kluczowych
ryzyk są
dobierane
zabezpieczenia
• Zdefiniowanie
wymagań
Projektowanie
• Wymagania są
weryfikowane w
projekcie
Wykonanie
• Testy
jednostkowe
zabezpieczeń i
poprawności
kodu (według
przyjętych
wymagań)
Wdrażanie
• Testy odbiorcze
– w zakresie
odpowiadającym
przyjętym
wymaganiom
Wymagania
Szara rzeczywistość
• Brak założeń
• Brak kwestii niefunkcjonalnych
(SQLi, XSS, CSRF, kontrola dostępu, logika, …)
• Brak uwzględnienia realnych scenariuszy ataku

6. 6
Od czego zacząć?
Modelowanie zagrożeń
(Threat Modeling)

7. 7
Płacenie za zakupy w sklepie
aplikacją mobilną
Klient: Wybiera „ZAPŁAĆ” w swojej
aplikacji mobilnej. Generowany jest
KOD.
Kasjer: Wprowadza KOD i kwotę do
aplikacji kasowej
Klient: Akceptuje transakcję w swojej
aplikacji mobilnej

8. 8
Inne funkcje apki mobilnej
Historia transakcji
Zmiana PIN

9. 9
Aktywacja aplikacji przez
Klienta
W aplikacji operatora:
 Podaje nr telefonu i skojarzony
rachunek / nr karty / …
 Ustala PIN (hasło do aplikacji)
 Generuje KOD STARTOWY
W aplikacji mobilnej:
 Wprowadza NR TELEFONU i KOD
STARTOWY

10. 10
Rejestracja sklepu
Manager sklepu: Wprowadza dane
sklepu i nr rachunku rozliczeniowego
w aplikacji operatora

11. 11
DFD

12. 12
Modelowanie zagrożeń (cz.1)

13. 13
Live cooking ;)

14. 14

15. 15
Co chronimy?

16. 16
Kto może atakować?

17. 17
Co może się stać?

18. 18
Cele atakującego

19. 19
Scenariusze ataków
Dekompozycja (attack trees)

20. 20
Scenariusze ataków (c.d.)
…itd. dla
wszystkich celów
atakującego

21. 21
Dobranie zabezpieczeń
Przykład 1:

22. 22
Dobranie zabezpieczeń
Przykład 2:

23. 23
…itd. aż przeanalizujemy
wszystkie scenariusze ataku

24. 24
Proces modelowania zagrożeń

25. 25
Proces modelowania zagrożeń
(c.d.)

26. 26
Podsumowanie
Modelowanie zagrożeń daje:
 Wyeliminowanie błędów projektowych
 Wymagania odnośnie bezpieczeństwa
 Dopasowanie zabezpieczeń do ryzyk
 Uwzględnienie najistotniejszych
zagrożeń i ryzyk
 Wyzwala myślenie o bezpieczeństwie

27. 27
Podsumowanie (c.d)
Modelowanie zagrożeń nie daje:
 Pewności że nie ma defektów
bezpieczeństwa
 Mogą zostać wprowadzone na etapie
implementacji
Jako uzupełnienie:
 OWASP ASVS (Application Security
Verification Standard)
 Zasady dobrej praktyki – lista kontrolna

28. 28
Dziękuję za uwagę
http://www.securing.pl
e-mail: info@securing.pl
Jontkowa Górka 14a
30-224 Kraków
tel. (12) 4252575
fax. (12) 4252593
Wojciech Dworakowski
wojciech.dworakowski@securing.pl
tel. 506 184 550