Bezpieczeństwo w cyklu życia oprogramowania Wojciech Dworakowski SecuRing [email protected] OWASP 2010-01-14 Copyright © The OWASP Foundation Permission is granted to copy, distribute and/or modify this document under the terms.
Download
Report
Transcript Bezpieczeństwo w cyklu życia oprogramowania Wojciech Dworakowski SecuRing [email protected] OWASP 2010-01-14 Copyright © The OWASP Foundation Permission is granted to copy, distribute and/or modify this document under the terms.
Bezpieczeństwo w cyklu życia
oprogramowania
Wojciech Dworakowski
SecuRing
[email protected]
OWASP
2010-01-14
Copyright © The OWASP Foundation
Permission is granted to copy, distribute and/or modify this document
under the terms of the OWASP License.
The OWASP Foundation
http://www.owasp.org
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
2
Teoria
Wdrażanie
Utrzymanie
Wytwarzanie
Projektowanie
Definiowanie
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 implementacji
Przeglądy dokumentacji i kodu projektu
Testy 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 Statistics
http://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
- Definiowanie
Zdefiniowanie 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
- Projektowanie
Weryfikacja 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
- Wytwarzanie
Bieżą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żanie
Przetestowanie 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
Zależność „finish to start”
Testy
funkcjonalne
Testy
bezpieczeństwa
Pilotaż
Go live
Poprawki !
Usunięte
podatności
OWASP
Praktyka
- Utrzymanie
Testowanie 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
Wykonawca
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ń
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
OWASP SAMM
http://www.opensamm.org
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ściowy
1. Ogólne zrozumienie i stosowanie „ad hoc”
2. Zwiększenie sprawności i/lub efektywności
3. 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
Źródło: www.opensamm.org
Źródło: www.owasp.org
OWASP
OWASP SAMM
http://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 SDL
http://www.microsoft.com/sdl
Microsoft Security Development Lifecycle
Praktyki wypracowane przy tworzeniu oprogramowania w MS
Bardziej szczegółowe niż SAMM
SDL 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
Wykonawca
Zleceniodawca
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)
OWASP
25
W sieci…
Standardy, benchmarki:
OWASP Guide
OWASP Top 10
CWE/SANS Top 25 Most Dangerous Programming Errors
http://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/
OWASP
26
„Kontrola najwyższą formą zaufania” ;)
Dziękuję za uwagę
Wojciech Dworakowski
[email protected]
OWASP