Pobieranie prezentacji. Proszę czekać

Pobieranie prezentacji. Proszę czekać

Copyright © The OWASP Foundation Permission is granted to copy, distribute and/or modify this document under the terms of the OWASP License. The OWASP.

Podobne prezentacje


Prezentacja na temat: "Copyright © The OWASP Foundation Permission is granted to copy, distribute and/or modify this document under the terms of the OWASP License. The OWASP."— Zapis prezentacji:

1 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 OWASP Bezpieczeństwo w cyklu życia oprogramowania Wojciech Dworakowski SecuRing

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

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

4 OWASP Teoria DefiniowanieZdefiniowanie wymagań bezpieczeństwa (niefunkcjonalnych) Zweryfikowanie metodyki wytwarzania oprogramowania ProjektowanieWeryfikacja cech bezpieczeństwa na etapie projektowania WytwarzanieBieżąca kontrola w trakcie implementacji Przeglądy dokumentacji i kodu projektu Testy jednostkowe WdrażaniePrzetestowanie całości przed wdrożeniem UtrzymanieSprawdzanie okresowe i przy zmianach

5 OWASP Praktyka – trochę statystyki Większość aplikacji tworzonych na zamówienie posiada istotne podatności (o znacznym wpływie na ryzyko) Threat rankN of VulnsN of Sites % Sites Urgent %18.77% Critical %45.22% High %72.27% Medium %36.56% Low %29.69% 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 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 Na tym etapie można już tylko liczyć na mniej lub bardziej nieeleganckie obejście problemu Łata a nie naprawa

7 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

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

9 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) ale to są de facto testy przedwdrożeniowe

10 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 Uwaga: ciężko oszacować bo ilość i jakość poprawek jest niewiadomą Często: testowanie po wdrożeniu

11 OWASP Syndrom gumowego czasu Testy funkcjonalne Testy bezpieczeństwa Pilotaż Poprawki ! Zależność finish to start

12 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

13 OWASP Wishful thinking Zamawiający 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ń 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

14 OWASP 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 OWASP 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 OWASP 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 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 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ą: Cel Czynności Pytania do audytu Rezultat wdrożenia Miara sukcesu Wpływ na koszty, niezbędny personel OWASP SAMM Źródło: Źródło:

18 OWASP OWASP SAMM 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 OWASP Microsoft 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 OWASP OpenSAMM a aplikacja zamawiana Część procesów jest pod kontrolą zewnętrznego Wykonawcy Większy nacisk na definiowanie wymagań Wyegzekwowanie wymagań od Wykonawcy GovernanceConstructionVerificationDeployment Zleceniodawca Wykonawca

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

26 OWASP 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) 26

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


Pobierz ppt "Copyright © The OWASP Foundation Permission is granted to copy, distribute and/or modify this document under the terms of the OWASP License. The OWASP."

Podobne prezentacje


Reklamy Google