1 / 27

Bezpieczeństwo w cyklu życia oprogramowania

Bezpieczeństwo w cyklu życia oprogramowania. Wojciech Dworakowski SecuRing wojciech.dworakowski@securing.pl. 2010-01-14. Agenda. Teoria a praktyka Teoria Kilka przykładów z praktyki Przyczyny takiego stanu rzeczy

kiana
Download Presentation

Bezpieczeństwo w cyklu życia oprogramowania

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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

More Related