Copyright © The OWASP FoundationPermission is granted to copy, distribute and/or modify this document under the terms of the OWASP License.
The OWASP Foundation
OWASP
http://www.owasp.org
Bezpieczeństwo w cyklu życia oprogramowania
Wojciech [email protected]
2010-01-14
OWASP 2
Agenda
Teoria a praktyka Teoria Kilka przykładów z praktyki Przyczyny takiego stanu rzeczy
Co zrobić i od czego zacząć? Wprowadzenie do modelów dojrzałości bezpieczeństwa oprogramowania OWASP SAMM (Security Assurance Maturity Model) Microsoft Security Development Lifecycle
Tips & Tricks Kilka łatwych do wprowadzenia zmian
Podsumowanie
OWASP
Teoria
Definiowanie
Projektowanie
Wytwarzanie
Wdrażanie Utrzymanie
Rosnące koszty usuwania podatności
OWASP
Teoria
Definiowanie Zdefiniowanie wymagań bezpieczeństwa (niefunkcjonalnych)Zweryfikowanie metodyki wytwarzania oprogramowania
Projektowanie Weryfikacja cech bezpieczeństwa na etapie projektowania
Wytwarzanie Bieżąca kontrola w trakcie implementacjiPrzeglądy dokumentacji i kodu projektuTesty jednostkowe
Wdrażanie Przetestowanie całości przed wdrożeniem
Utrzymanie Sprawdzanie okresowe i przy zmianach
OWASP
Praktyka – trochę statystyki
Większość aplikacji tworzonych na zamówienie posiada istotne podatności (o znacznym wpływie na ryzyko)Threat rank N of Vulns N of Sites N of Sites % Sites
Urgent 8918 2287 9.14% 18.77%
Critical 44669 5511 45.79% 45.22%
High 35375 8807 36.26% 72.27%
Medium 4908 4455 5.03% 36.56%
Low 3663 3618 3.75% 29.69%
24678 aplikacji przebadanych metodami testu penetracyjnego black-box, white-box oraz skanerami automatycznymi w roku 2008 (8 różnych firm)Źródło: WASC Web Application Secuirty Statisticshttp://projects.webappsec.org/Web-Application-Security-Statistics
OWASP
Praktyka – z naszych doświadczeń
Zleceniodawcami są wyłącznie użytkownicy końcowi
W większości tylko testy bezpieczeństwa Testy najczęściej są zamawiane tuż przed
wdrożeniem produkcyjnym (90% zleceń) Kluczowe podatności znajdujemy w ok. 70%
badanych aplikacji Na tym etapie można już tylko liczyć na mniej lub
bardziej nieeleganckie obejście problemu „Łata” a nie naprawa
OWASP
Praktyka- DefiniowanieZdefiniowanie wymagań bezpieczeństwa (również
niefunkcjonalnych) Często nie ma zdefiniowanych żadnych wymagań Brak zidentyfikowanych zagrożeń (poza intuicją) Brak wewnętrznych standardów bezpiecznego
kodowania Ma być „bezpiecznie”
People can only do the right thing, if they know what the right thing is.
Mark Curphey – OWASP Testing Framework
OWASP
Praktyka- ProjektowanieWeryfikacja cech bezpieczeństwa na etapie
projektowania Często nie ma formalnego (spisanego) projektu Jeśli nie ma zdefiniowanych wymagań (pkt.1) to
nie ma czego weryfikować Jeśli nawet jest formalnie opisany projekt
aplikacji, to bezpieczeństwo jest opisane tylko odnośnie cech funkcjonalnych (uwierzytelnianie, autoryzacja operacji, itd.)
OWASP
Praktyka- WytwarzanieBieżąca kontrola w trakcie implementacji Założenia zmieniają się w trakcie trwania projektu Wykonawca nie prowadzi testów jednostkowych Są prowadzone testy bezpieczeństwa w miarę
oddawania kolejnych funkcjonalności (równolegle z testami funkcjonalnymi) ale to są de facto testy przedwdrożeniowe
OWASP
Praktyka- WdrażaniePrzetestowanie całości przed wdrożeniem W większości przypadków są to jedyne testy
bezpieczeństwa Często: zależność typu „end to end” Często: brak przewidzianego czasu na poprawki
Uwaga: ciężko oszacować bo ilość i jakość poprawek jest niewiadomą
Często: testowanie po wdrożeniu
OWASP
Syndrom „gumowego” czasu
Testy funkcjonalne
Testy bezpieczeństwa
Pilotaż
Go live
Poprawki !
Usunięte podatnośc
i
Zależność „finish to start”
OWASP
Praktyka- UtrzymanieTestowanie wpływu każdej zmiany Rzadko są prowadzone dzienniki zmian na
poziomie niższym niż funkcjonalny (opisanie tylko widocznych zmian)
Testy okresowe – zdarzają się, ale nie są regułą nawet dla kluczowych aplikacji
OWASP
„Wishful thinking”
Zamawiający Wykonawcą jest
doświadczona firma, z pewnością wiedzą co robią
Ich oprogramowania używają duże firmy – oni nie pozwoliliby sobie na niską jakość
Testy bezpieczeństwa zaplanujemy N dni wstecz od wdrożenia produkcyjnego / pilotażowego
Raczej nie będzie żadnych opóźnień
Wykonawca Zatrudniamy doświadczonych
programistów, z pewnością wiedzą co robią
Nasze nowoczesne narzędzia (famework, biblioteki) nie pozwolą na wykorzystanie ewentualnych niedoskonałości
Nie otrzymaliśmy żadnych szczegółowych wytycznych – Pewnie ryzyko będzie ograniczone innymi metodami
OWASP
Efekty
Przykład 1 Wiele podatności o dużym wpływie na ryzyko
(kontrola dostępu, sql injection, stored xss) Testy w trakcie pilotażu. Rozpoczęta kampania informacyjna. Przesunięcie wdrożenia produkcyjnego o ponad miesiąc
Przykład 2 Badanie pogłębione o przegląd kodu N dni przed wdrożeniem Wnioski z przeglądu nie dały się w żaden sposób
spożytkować
OWASP
Efekty
Przykład 3 Przegląd konfiguracji Wykonawca nie wiedział, że Zleceniodawca ma jakieś
wewnętrzne regulacje dotyczące „hardenningu” Przykład 4
Żeby usunąć podatność, zastosowano obejście problemu My zastosowaliśmy obejście obejścia Wykrycie Poprawienie Weryfikacja Poprawienie
Weryfikacja - …..
OWASP
Bezpieczeństwo w procesie tworzenia oprogramowania Bezpieczeństwo powinno być wpisane w proces
rozwojowy aplikacji Software Development Lifecycle Security Development
Lifecycle Ciężko jest „dołożyć” bezpieczeństwo na końcu Czy rzeczywiście wdrożenie SDLC jest takie
skomplikowane? Można przygotować założenia ogólne – dla każdej
aplikacji Zadanie jednorazowe Można wykorzystać istniejące opracowania (np. OWASP
Guide, Microsoft SDL) Wystarczy uzupełnić proces tworzenia / zamawiania
oprogramowania o kwestie bezpieczeństwa Są gotowe opracowania pozwalające na szybkie
wdrożenie SDLC
OWASP
Software Assurance Maturity Model Model dojrzałości
4 Business Functions x 3 Security Practices Każda z 12 „security practices” ma zdefiniowane 3 poziomy
dojrzałości + poziom 0 jako punkt wyjściowy1. Ogólne zrozumienie i stosowanie „ad hoc”2. Zwiększenie sprawności i/lub efektywności3. Wszechstronne stosowanie i dostosowanie do skali
Dla każdej praktyki / poziomu dojrzałości opisane są: Cel Czynności Pytania do audytu Rezultat wdrożenia Miara sukcesu Wpływ na koszty, niezbędny personel
OWASP SAMMhttp://www.opensamm.org
Źródło: www.owasp.org
Źródło: www.opensamm.org
OWASP
OWASP SAMMhttp://www.opensamm.org Model uproszczony ale dość elastyczny Lista kontrolna do przeprowadzania oceny
procesów Raczej dla całej firmy ale można zastosować tylko
dla konkretnego projektu Roadmaps dla różnych typów organizacji
Pokazują jakimi etapami wdrażać „security practices” dla różnych typów organizacji
ISV, Online Service Provider, Financial Services, Goverment Organizations
OWASP
Microsoft SDLhttp://www.microsoft.com/sdl
Microsoft Security Development Lifecycle Praktyki wypracowane przy tworzeniu oprogramowania w
MS Bardziej szczegółowe niż SAMMSDL Optimization Model 5 faz, 4 poziomy Self Assessment– Samoocena – gdzie
jesteśmy? Instrukcje przejścia na wyższy
poziom dojrzałości
OWASP
OpenSAMM a aplikacja zamawiana
Część procesów jest pod kontrolą zewnętrznego Wykonawcy Większy nacisk na definiowanie wymagań Wyegzekwowanie wymagań od Wykonawcy
Governance Construction Verification Deployment
Zleceniodawca
Wykonawca
OWASP
Potencjalne problemy
Łatwiej się wdraża o ile procesy są uporządkowane (ITIL, CobIT)
Często nie stosuje żadnych metodyk zarządzania projektem „Stosujemy własną metodykę” Ciężko jest dołożyć działania związane z bezpieczeństwem
jeśli nie ma ich gdzie „umocować” Koszty
W większości jednorazowe Ważne żeby nie stawiać sobie zbyt wygórowanych celów
OWASP
Kilka prostych zmian
Definiowanie projektu Nakazać definiowanie założeń dla każdego projektu Założenia
Na podstawie zagrożeń i oceny ryzyka (może być intuicyjnie)
Również niefunkcjonalne! Przygotowanie
Dostawca Sprawdzić gdzie jesteśmy SAMM Assessment worksheet
Zlecanie Uwzględnić bezpieczeństwo już podczas wyboru wykonawcy
Np.: Poprosić o wypełnienie „SAMM Assessment worksheet” Uwzględnienie bezpieczeństwa w umowie
Wypełnione listy kontrolne – jako oświadczenie Wykonawcy Założenia odnośnie bezpieczeństwa
OWASP
Kilka prostych zmian
W trakcie wykonania Kontrolować wykonanie założeń
Przynajmniej na okresowych spotkaniach Spisać notatki ze spotkania
Sprecyzować oczekiwania – dyskutować z Wykonawcą Testy
Zaplanować testy bezpieczeństwa odpowiednio wcześnie
Po ustabilizowaniu kodu Przed pilotażem
W harmonogramie uwzględnić czas potrzebny na poprawki
Przedyskutować z Wykonawcą
OWASP
Podsumowanie
Bezpieczeństwo wciąż należy do tego rodzaju zagadnień, które jeśli nie zostaną poruszone wprost, to nikt się nimi nie zajmie W odróżnieniu do funkcjonalności czy wydajności
bezpieczeństwa nie widać Dlatego łatwo je zgubić ;)
Ciężko jest „dołożyć” bezpieczeństwo na końcu Absolutne minimum
Definiowanie wymagań Wymagania (niefunkcjonalne) dotyczące bezpieczeństwa
powinny być zdefiniowane Testowanie
Testowanie i usuwanie podatności trzeba przewidzieć w harmonogramie projektu
OWASP
Co zmienić?
Nie jest konieczna rewolucja Analiza braków w SDLC (SAMM Assessment worksheet) Wprowadzenie najistotniejszych zmian – adekwatnie do
ryzyka Długoterminowo najlepsze efekty przynosi
wprowadzenie zmian w najwcześniejszych fazach: Edukacja Opracowanie uniwersalnych standardów
Krótkoterminowo (dla projektów w trakcie): Testowanie (testy penetracyjne, przeglądy kodu) Spożytkowanie wniosków z testów (co da się poprawić
bez przepisywania całości projektu)
25
OWASP
W sieci…
Standardy, benchmarki: OWASP Guide OWASP Top 10 CWE/SANS Top 25 Most Dangerous Programming
Errorshttp://cwe.mitre.org/top25/
Modele dojrzałości: Software Assurance Maturity Model (SAMM)
http://www.opensamm.org/ Microsoft SDL http://www.microsoft.com/sdl The Building Security In Maturity Model (BSIMM)
http://bsi-mm.com/ 26