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
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
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
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
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
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