Bezpieczeństwo w cyklu życia oprogramowania

Prezentacja na temat: "Bezpieczeństwo w cyklu życia oprogramowania"— Zapis prezentacji:

1 Bezpieczeństwo w cyklu życia oprogramowania
Wojciech Dworakowski SecuRing

2 Agenda Teoria a praktyka
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

3 Teoria Rosnące koszty usuwania podatności Utrzymanie Wdrażanie
Definiowanie Projektowanie Wytwarzanie Wdrażanie Utrzymanie Rosnące koszty usuwania podatności

4 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

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

6 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

7 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

8 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.)

9 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

10 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

11 Syndrom „gumowego” czasu
Zależność „finish to start” Testy funkcjonalne Testy bezpieczeństwa Pilotaż Go live Poprawki ! Usunięte podatności

12 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

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

14 Efekty Przykład 1 Przykład 2
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ć

15 Efekty Przykład 3 Przykład 4 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 - …..

16 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

17 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 Ogólne zrozumienie i stosowanie „ad hoc” Zwiększenie sprawności i/lub efektywności 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: Źródło:

18 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

19 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

20 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

21 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

22 Kilka prostych zmian Definiowanie projektu Przygotowanie
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

23 Kilka prostych zmian W trakcie wykonania Testy
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ą

24 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

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

26 W sieci… Standardy, benchmarki: OWASP Guide OWASP Top 10
CWE/SANS Top 25 Most Dangerous Programming Errors Modele dojrzałości: Software Assurance Maturity Model (SAMM) Microsoft SDL The Building Security In Maturity Model (BSIMM)

27 „Kontrola najwyższą formą zaufania” ;)
Dziękuję za uwagę Wojciech Dworakowski