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

The OWASP Foundation

OWASP

http://www.owasp.org

Bezpieczeństwo w cyklu życia oprogramowania

Wojciech DworakowskiSecuRingwojciech.dworakowski@securing.pl

2010-01-14

OWASP 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 Assurance Maturity Model) Microsoft Security Development Lifecycle

Tips & Tricks Kilka łatwych do wprowadzenia zmian

Podsumowanie

OWASP

Teoria

Definiowanie

Projektowanie

Wytwarzanie

Wdrażanie Utrzymanie

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 implementacjiPrzeglądy dokumentacji i kodu projektuTesty 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 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 Statisticshttp://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 Na tym etapie można już tylko liczyć na mniej lub

bardziej nieeleganckie obejście problemu „Łata” a nie naprawa

OWASP

Praktyka- DefiniowanieZdefiniowanie 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- ProjektowanieWeryfikacja 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- WytwarzanieBieżą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

OWASP

Praktyka- WdrażaniePrzetestowanie 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

OWASP

Syndrom „gumowego” czasu

Testy funkcjonalne

Testy bezpieczeństwa

Pilotaż

Go live

Poprawki !

Usunięte podatnośc

i

Zależność „finish to start”

OWASP

Praktyka- UtrzymanieTestowanie 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 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

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ć

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

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

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ściowy1. Ogólne zrozumienie i stosowanie „ad hoc”2. Zwiększenie sprawności i/lub efektywności3. 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 SAMMhttp://www.opensamm.org

Źródło: www.owasp.org

Źródło: www.opensamm.org

OWASP

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

OWASP

Microsoft SDLhttp://www.microsoft.com/sdl

Microsoft Security Development Lifecycle Praktyki wypracowane przy tworzeniu oprogramowania w

MS Bardziej szczegółowe niż SAMMSDL Optimization Model 5 faz, 4 poziomy Self Assessment– Samoocena – gdzie

jesteśmy? Instrukcje przejścia na wyższy

poziom dojrzałości

OWASP

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

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

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

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ą

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

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

OWASP

W sieci…

Standardy, benchmarki: OWASP Guide OWASP Top 10 CWE/SANS Top 25 Most Dangerous Programming

Errorshttp://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/ 26

OWASP

„Kontrola najwyższą formą zaufania” ;)

Dziękuję za uwagę

Wojciech Dworakowskiwojciech.dworakowski@securing.pl