Bezpieczestwo w cyklu ycia oprogramowania Wojciech Dworakowski Secu

Bezpieczeństwo w cyklu życia oprogramowania Wojciech Dworakowski Secu. Ring wojciech. dworakowski@securing. pl 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 4 Teoria 4 Kilka przykładów z praktyki 4 Przyczyny takiego stanu rzeczy < Co zrobić i od czego zacząć? Wprowadzenie do modelów dojrzałości bezpieczeństwa oprogramowania 4 OWASP SAMM (Security Assurance Maturity Model) 4 Microsoft Security Development Lifecycle < Tips & Tricks 4 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 % 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 4 Na tym etapie można już tylko liczyć na mniej lub bardziej nieeleganckie obejście problemu 4 „Ł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) 4 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 4 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 4 Wiele podatności o dużym wpływie na ryzyko (kontrola dostępu, sql injection, stored xss) 4 Testy w trakcie pilotażu. 4 Rozpoczęta kampania informacyjna. 4 Przesunięcie wdrożenia produkcyjnego o ponad miesiąc < Przykład 2 4 Badanie pogłębione o przegląd kodu 4 N dni przed wdrożeniem 4 Wnioski z przeglądu nie dały się w żaden sposób spożytkować OWASP

Efekty < Przykład 3 4 Przegląd konfiguracji 4 Wykonawca nie wiedział, że Zleceniodawca ma jakieś wewnętrzne regulacje dotyczące „hardenningu” < Przykład 4 4 Żeby usunąć podatność, zastosowano obejście problemu 4 My zastosowaliśmy obejście obejścia 4 Wykrycie Poprawienie Weryfikacja - …. . OWASP

Bezpieczeństwo w procesie tworzenia oprogramowania < Bezpieczeństwo powinno być wpisane w proces rozwojowy aplikacji 4 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? 4 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) 4 Wystarczy uzupełnić proces tworzenia / zamawiania oprogramowania o kwestie bezpieczeństwa 4 Są gotowe opracowania pozwalające na szybkie wdrożenie SDLC OWASP

OWASP SAMM http: //www. opensamm. org < Software Assurance Maturity Model 4 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ą: 4 Cel 4 Czynności 4 Pytania do audytu 4 Rezultat wdrożenia 4 Miara sukcesu 4 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 4 Pokazują jakimi etapami wdrażać „security practices” dla różnych typów organizacji 4 ISV, Online Service Provider, Financial Services, Goverment Organizations OWASP

Microsoft SDL http: //www. microsoft. com/sdl < Microsoft Security Development Lifecycle 4 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

Open. SAMM a aplikacja zamawiana < Część procesów jest pod kontrolą zewnętrznego Wykonawcy 4 Większy nacisk na definiowanie wymagań 4 Wyegzekwowanie wymagań od Wykonawcy Governance Construction Verification Deployment Wykonawca Zleceniodawca OWASP

Potencjalne problemy < Łatwiej się wdraża o ile procesy są uporządkowane (ITIL, Cob. IT) < Często nie stosuje żadnych metodyk zarządzania projektem 4 „Stosujemy własną metodykę” 4 Ciężko jest dołożyć działania związane z bezpieczeństwem jeśli nie ma ich gdzie „umocować” < Koszty 4 W większości jednorazowe 4 Ważne żeby nie stawiać sobie zbyt wygórowanych celów OWASP

Kilka prostych zmian < Definiowanie projektu 4 Nakazać definiowanie założeń dla każdego projektu 4 Założenia § Na podstawie zagrożeń i oceny ryzyka (może być intuicyjnie) § Również niefunkcjonalne! < Przygotowanie 4 Dostawca Sprawdzić gdzie jesteśmy § SAMM Assessment worksheet 4 Zlecanie Uwzględnić bezpieczeństwo już podczas wyboru wykonawcy § Np. : Poprosić o wypełnienie „SAMM Assessment worksheet” 4 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 4 Kontrolować wykonanie założeń § Przynajmniej na okresowych spotkaniach § Spisać notatki ze spotkania 4 Sprecyzować oczekiwania – dyskutować z Wykonawcą < Testy 4 Zaplanować testy bezpieczeństwa odpowiednio wcześnie § Po ustabilizowaniu kodu § Przed pilotażem 4 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 4 W odróżnieniu do funkcjonalności czy wydajności bezpieczeństwa nie widać 4 Dlatego łatwo je zgubić ; ) < Ciężko jest „dołożyć” bezpieczeństwo na końcu < Absolutne minimum 4 Definiowanie wymagań § Wymagania (niefunkcjonalne) dotyczące bezpieczeństwa powinny być zdefiniowane 4 Testowanie § Testowanie i usuwanie podatności trzeba przewidzieć w harmonogramie projektu OWASP

Co zmienić? < Nie jest konieczna rewolucja 4 Analiza braków w SDLC (SAMM Assessment worksheet) 4 Wprowadzenie najistotniejszych zmian – adekwatnie do ryzyka < Długoterminowo najlepsze efekty przynosi wprowadzenie zmian w najwcześniejszych fazach: 4 Edukacja 4 Opracowanie uniwersalnych standardów < Krótkoterminowo (dla projektów w trakcie): 4 Testowanie (testy penetracyjne, przeglądy kodu) 4 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/top 25/ 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 wojciech. dworakowski@securing. pl OWASP