Bezpieczeństwo w cyklu życia oprogramowania Wojciech Dworakowski SecuRing wojciech.dworakowski@securing.pl 2010-01-14

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

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

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

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 http://projects.webappsec.org/Web-Application-Security-Statistics

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

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

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

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

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

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

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

„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

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ć

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

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 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: www.opensamm.org Źródło: www.owasp.org

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

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

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

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

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

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ą

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

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)

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/

„Kontrola najwyższą formą zaufania” ;) Dziękuję za uwagę Wojciech Dworakowski wojciech.dworakowski@securing.pl