Prezentacja z konferencji ISSA InfoTRAMS Holistic Application Security Od kilku lat na świecie jest promowane podejście polegające na wpisaniu bezpieczeństwa w cały cykl rozwojowy oprogramowania. W polskiej praktyce, nadal kwestie związane z bezpieczeństwem najczęściej poruszane są na dopiero na końcu projektu, tuż przed wdrożeniem gdy wykonywane są testy bezpieczeństwa. Bardzo często takie podejście skutkuje znacznymi kosztami usuwania błędów i sporym "zamieszaniem" w projekcie, ale o tym firma przekonuje się dopiero "za 5 dwunasta", po wykonaniu testów bezpieczeństwa. Z reguły, usuwanie podatności na tym etapie projektu polega na "gaszeniu pożarów" i przyklejaniu kolejnych łatek zamiast wprowadzenia systemowych zmian. W rezultacie, w dalszym cyklu życia, po wprowadzeniu zmian funkcjonalnych wypływają nowe przypadki wystąpienia starych błędów. Jak to zmienić? Czy zastosowanie podstawowych zasad tworzenia bezpiecznego oprogramowania jest faktycznie takie skomplikowane jak by mogło się wydawać? W trakcie prezentacji zostaną przedstawione metodyki wprowadzania bezpieczeństwa do całego cyklu rozwojowego oprogramowania (na przykładzie OWASP SAMM), również z uwzględnieniem sytuacji, gdy stworzenie aplikacji zlecane jest dla firmy zewnętrznej. Krótko omówiona zostanie skuteczność i potencjalne problemy tych metodyk w naszych, polskich realiach. Przedstawione zostanie także kilka prostych sposobów, które zdaniem autora pozwolą na skuteczniejsze osiągnięcie zamierzonego efektu - czyli aplikacji nieobarczonej podatnościami.

1. Jak tworzyć (lub zamawiać)
bezpieczne aplikacje?
Wojciech Dworakowski

2. # whoami
SecuRing (od 2003)
 Testowanie i doradztwo dotyczące
bezpieczeństwa aplikacji i systemów IT
 Badania dotyczące nowych metod
ataku i obrony
OWASP Poland Chapter Leader
 Propagowanie wiedzy związanej z
bezpieczeństwem aplikacji
2

3. Historia pewnej aplikacji
3

4. 4

5. XSS idea ;)
5

6. Hook
6

7. Listener
7

8. Uruchamia się exploit –
żadnych widocznych skutków
8

9. Połączenie od aplikacji
„wewnętrznej”
9

10. Sesja aplikacji wewnętrznej w
przeglądarce atakującego
10

11. … jest też SQLi
11

12. Struktura danych
12

13. Dane
13

14. Jak „usuwano” błędy
’
Dodatkowy znak żeby chronić przed
osadzaniem XSS / SQLi
 Obejście: ’’,
, …
Filtrowanie komend SQL
 Obejście: kodowanie znaków, inna
notacja, SQL hacks …
14

15. 15

16. Popełnione błędy
Zabezpieczenia tylko na styku z siecią
publiczną
Brak dbałości o bezpieczeństwo „od
wewnątrz”
Nieprawidłowo
zdefiniowane
wymagania
Nieprawidłowy
zakres testów
16

17. 17

18. Popełnione błędy
Brak wiedzy programistów w zakresie
bezpieczeństwa
Niewłaściwie zdefiniowane wymagania
Podatności
 XSS
 SQL injection
18

19. 19

20. Projektowanie
Analiza i zdefiniowanie wymagań
dotyczących bezpieczeństwa
 Całość systemu
 Połączenia z innymi systemami
 Scenariusze ataku
 Dobranie zabezpieczeń (wymagań)
 Uwzględnienie wymagań
niefunkcjonalnych
20

21. Projektowanie
Narzędzia
Analiza i zdefiniowanie wymagań
 Modelowanie
dotyczących bezpieczeństwa
zagrożeń
(Threat Modeling)
 Całość systemu
 systemami
 Połączenia z innymi OWASP ASVS
 Scenariusze ataku
 Dobranie zabezpieczeń (wymagań)
 Uwzględnienie wymagań
niefunkcjonalnych
21

22. Wykonanie
Zasady bezpiecznego programowania
 Edukacja
 Kontrola
Weryfikacja przyjętych założeń
 Okresowe przeglądy wymagań
 Testy jednostkowe
Narzędzia
22

23. Wykonanie
Narzędzia
Zasady bezpiecznego programowania
 OWASP
 Edukacja
Development Guide
 Kontrola
 OWASP Cheat
Sheet Series
Weryfikacja przyjętych założeń
 Okresowe przeglądy wymagań
 Testy jednostkowe
Narzędzia
23

24. Wdrażanie
Testy bezpieczeństwa
 Na podstawie przyjętych wymagań
 Objęcie całości systemu
 Zweryfikowanie realnych scenariuszy
ataku
– źródła zagrożeń
– cele atakującego
24

25. Wdrażanie
Narzędzia
Testy bezpieczeństwa
 OWASP Testing
 Na podstawie przyjętych wymagań
Guide
 Objęcie całości systemu
 OWASP ASVS
 Zweryfikowanie realnych scenariuszy
ataku
– źródła zagrożeń
– cele atakującego
25

26. Utrzymanie
Monitorowanie podatności
 Systemy
 Biblioteki
 Kod własny
Zarządzanie podatnościami
 Decyzje na podstawie ryzyka
 Okresowe testy weryfikacyjne
 Dokumentowanie poprawek
26

27. 27

28. 28

29. Standardy / modele dojrzałości
ISO/IEC 27034 - podejście procesowe
(na razie ukazała się tylko część 1)
BSIMM
http://bsimm.com
MS SDL http://microsoft.com/sdl
SAMM
http://opensamm.org
 Security Assurance Maturity Model
 Model dojrzałości dotyczący bezpieczeństwa
w procesie wytwarzania oprogramowania
29

30. SAMM
Software Assurance Maturity Model
4 Business Functions x 3 Security Practices
3 poziomy dojrzałości + poziom 0 jako punkt
wyjściowy
Stosowane w: Dell, ING Insurance International,
KBC, ISG, …
https://www.owasp.org/index.php/OpenSAMM_Adopters
30
Źródło: www.owasp.org

31. SAMM: Wdrażanie
Assessment  Kwestionariusz (str.22)
Scorecard (przed)
Plan wdrożenia (roadmap) - etapami
 Gotowe szablony dla typowych
instytucji
Opis konkretnych działań
wynikających z planu wdrożenia
31

32. Security Practices
Dla każdego poziomu – opis:
 Objective
 Activities
 Assessment
 Results
 Success Metrics
 Costs
 Personel
32

33. SAMM: Roadmap (ex.)
33

34. SAMM: Security Practices (ex.)
34

35. SAMM: Security Practices (ex.)
35

36. 36

37. Security Officer
Wdrożenie (elementów) SDLC
Analiza i definiowanie wymagań
 Również niefunkcjonalnych
 Przy uwzględnieniu połączeń
 Brainstorming / Modelowanie zagrożeń
Testy bezpieczeństwa
 Właściwie dobrany zakres
37

38. Architekt
Modelowanie zagrożeń
Właściwe wyznaczenie granic zaufania
Bezpieczna architektura
 Zabezpieczenia przeciwdziałające
scenariuszom ataku
 Wiele poziomów zabezpieczeń
(zgodnie z analizą ryzyka)
38

39. Project Manager
Podnoszenie świadomości zespołu w
zakresie bezpieczeństwa
 Scenariusze ataku
 Techniki bezpiecznego programowania
Wymagania
 Kontrolowanie podczas wykonania
 … i przed wdrożeniem (testy)
39

40. Testujący
Uwzględnij ryzyko
Uwzględnij logikę biznesową
Uwzględnij design
Uwzględnij połączenia z innymi
systemami
Whitebox ! Konsultacje z zespołem
projektowym
40

41. 41

42. Grafika:
http://flic.kr/p/LobZJ
Brian Hillegas
http://flic.kr/p/4NTqUr
UGArdener
http://flic.kr/p/9bF21n
akulawolf
http://flic.kr/p/M4C2b
Paco CT
http://flic.kr/p/hoMcw
Marcus Ramberg
This work is licensed under the Creative Commons AttributionNonCommercial-ShareAlike 3.0 Unported License. To view a copy of this
license, visit http://creativecommons.org/licenses/by-nc-sa/3.0/
42