Bezpieczeństwo w cyklu życia oprogramowania

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

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 AssuranceMaturity Model) • Microsoft Security Development Lifecycle • Tips & Tricks • Kilka łatwych do wprowadzenia zmian • Podsumowanie

3. Teoria Rosnące koszty usuwania podatności

4. Teoria

5. Praktyka – trochę statystyki • Większość aplikacji tworzonych na zamówienie posiada istotne podatności (o znacznym wpływie na ryzyko) 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

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ż Poprawki ! Go live 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 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 • 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ń

14. 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ć

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

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 SAMMhttp://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

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

19. Microsoft SDLhttp://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 Wykonawca Zleceniodawca

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 • 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 Assessmentworksheet • 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 • 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 Assessmentworksheet) • 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 DangerousProgrammingErrors http://cwe.mitre.org/top25/ Modele dojrzałości: • Software AssuranceMaturity Model (SAMM) http://www.opensamm.org/ • Microsoft SDL http://www.microsoft.com/sdl • The Building Security In Maturity Model (BSIMM) http://bsi-mm.com/

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